virtio DMA API, yet again

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++

 1 file changed, 24 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index e12e385f7ac3..4b8dab4960bb 100644
@@ -25,6 +25,30 @@
  #include 
  #include 

+/*
+ * The interaction between virtio and a possible IOMMU is a mess.
+ *
+ * On most systems with virtio, physical addresses match bus addresses,
+ * and it doesn't particularly matter whether we use the DMI API.
+ *
+ * On some sytems, including Xen and any system with a physical device
+ * that speaks virtio behind a physical IOMMU, we must use the DMA API
+ * for virtio DMA to work at all.
+ *

+ * On other systems, including SPARC and PPC64, virtio-pci devices are
+ * enumerated as though they are behind an IOMMU, but the virtio host
+ * ignores the IOMMU, so we must either pretend that the IOMMU isn't
+ * there or somehow map everything as the identity.
+ *
+ * For the time being, we preseve historic behavior and bypass the DMA
+ * API.
+ */

Quoted 32 lines · Andy Lutomirski

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++

 1 file changed, 24 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index e12e385f7ac3..4b8dab4960bb 100644
@@ -25,6 +25,30 @@
  #include 
  #include 

+/*
+ * The interaction between virtio and a possible IOMMU is a mess.
+ *
+ * On most systems with virtio, physical addresses match bus addresses,
+ * and it doesn't particularly matter whether we use the DMI API.
+ *
+ * On some sytems, including Xen and any system with a physical device
+ * that speaks virtio behind a physical IOMMU, we must use the DMA API
+ * for virtio DMA to work at all.
+ *
+ * On other systems, including SPARC and PPC64, virtio-pci devices are
+ * enumerated as though they are behind an IOMMU, but the virtio host
+ * ignores the IOMMU, so we must either pretend that the IOMMU isn't

Quoted 5 lines

+ * there or somehow map everything as the identity.
+ *
+ * For the time being, we preseve historic behavior and bypass the DMA
+ * API.
+ */

I spot at least three typos in there, FWIW. ('DMI API', 'sytems', 'preseve').

drivers/virtio/virtio_ring.c line 51

Quoted 5 lines

drivers/virtio/virtio_ring.c +5 -0

+static bool vring_use_dma_api(void)
+{
+	return false;
+}
+

I'd quite like to see this be an explicit opt-out for the known-broken platforms. We've listed the SPARC and PPC64 issues. For x86 I need to refresh my memory as a prelude to trying to fix it... was the issue *just* that Qemu tends to ship with a broken BIOS that misdescribes the virtio devices (and any assigned PCI devices) as being behind an IOMMU when they're not, in the rare case that Qemu actually exposes its partially-implemented virtual IOMMU to the guest?

Could we have an arch_vring_eschew_dma_api(dev) function which the affected architectures could provide (as a prelude to fixing it so that the DMA API does the right thing for *itself*)?

It would be functionally equivalent, but it would help to push the workarounds to the right place — rather than entrenching them for ever in tricky "OMG we need to audit what all the architectures do... let's not touch it!" code.

Signature · 2 lines

David Woodhouse                            Open Source Technology Centre
[email protected]                              Intel Corporation

Quoted 33 lines · David Woodhouse

Quoted 32 lines · Andy Lutomirski

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

drivers/virtio/virtio_ring.c +13 -0

index e12e385f7ac3..4b8dab4960bb 100644
@@ -25,6 +25,30 @@
 #include
 #include
 
+/*
+ * The interaction between virtio and a possible IOMMU is a mess.
+ *
+ * On most systems with virtio, physical addresses match bus addresses,
+ * and it doesn't particularly matter whether we use the DMI API.
+ *
+ * On some sytems, including Xen and any system with a physical device
+ * that speaks virtio behind a physical IOMMU, we must use the DMA API
+ * for virtio DMA to work at all.
+ *
+ * On other systems, including SPARC and PPC64, virtio-pci devices are
+ * enumerated as though they are behind an IOMMU, but the virtio host
+ * ignores the IOMMU, so we must either pretend that the IOMMU isn't

Quoted 8 lines

drivers/virtio/virtio_ring.c line 45

Quoted 5 lines

drivers/virtio/virtio_ring.c +5 -0

+ * there or somehow map everything as the identity.
+ *
+ * For the time being, we preseve historic behavior and bypass the DMA
+ * API.
+ */

I spot at least three typos in there, FWIW. ('DMI API', 'sytems', 'preseve').

Good catch, hopefully will be fixed in v2.

Quoted 15 lines

drivers/virtio/virtio_ring.c line 51

Quoted 6 lines

drivers/virtio/virtio_ring.c +5 -0

+static bool vring_use_dma_api(void)
+{
+   return false;
+}
+

I'd quite like to see this be an explicit opt-out for the known-broken platforms. We've listed the SPARC and PPC64 issues. For x86 I need to refresh my memory as a prelude to trying to fix it... was the issue *just* that Qemu tends to ship with a broken BIOS that misdescribes the virtio devices (and any assigned PCI devices) as being behind an IOMMU when they're not, in the rare case that Qemu actually exposes its partially-implemented virtual IOMMU to the guest?

Quoted 3 lines

Could we have an arch_vring_eschew_dma_api(dev) function which the affected architectures could provide (as a prelude to fixing it so that the DMA API does the right thing for *itself*)?

I'm fine with this.

Quoted 6 lines

Quoted 4 lines

Could we have an arch_vring_eschew_dma_api(dev) function which the affected architectures could provide (as a prelude to fixing it so that the DMA API does the right thing for *itself*)?

I'm fine with this.

I modified vring_use_dma_api to take a vring_virtqueue* parameter to make this easier.

I'm a bit torn here.  I want to get the mechanism and the Xen part in, and there's unlikely to be much debate on those as a matter of principle.  I'd also like to flip as many arches over as possible, but that could be trickier.  Let me mull over this.

Quoted 6 lines

Quoted 4 lines

Could we have an arch_vring_eschew_dma_api(dev) function which the affected architectures could provide (as a prelude to fixing it so that the DMA API does the right thing for *itself*)?

I'm fine with this.

I modified vring_use_dma_api to take a vring_virtqueue* parameter to make this easier.

I'm a bit torn here.  I want to get the mechanism and the Xen part in, and there's unlikely to be much debate on those as a matter of principle.  I'd also like to flip as many arches over as possible, but that could be trickier.  Let me mull over this.

Quoted 6 lines

Quoted 4 lines

Could we have an arch_vring_eschew_dma_api(dev) function which the affected architectures could provide (as a prelude to fixing it so that the DMA API does the right thing for *itself*)?

I'm fine with this.

I modified vring_use_dma_api to take a vring_virtqueue* parameter to make this easier.

I'm a bit torn here.  I want to get the mechanism and the Xen part in, and there's unlikely to be much debate on those as a matter of principle.  I'd also like to flip as many arches over as possible, but that could be trickier.  Let me mull over this.

Quoted 33 lines · David Woodhouse

Quoted 32 lines · Andy Lutomirski

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

drivers/virtio/virtio_ring.c +13 -0

index e12e385f7ac3..4b8dab4960bb 100644
@@ -25,6 +25,30 @@
 #include
 #include
 
+/*
+ * The interaction between virtio and a possible IOMMU is a mess.
+ *
+ * On most systems with virtio, physical addresses match bus addresses,
+ * and it doesn't particularly matter whether we use the DMI API.
+ *
+ * On some sytems, including Xen and any system with a physical device
+ * that speaks virtio behind a physical IOMMU, we must use the DMA API
+ * for virtio DMA to work at all.
+ *
+ * On other systems, including SPARC and PPC64, virtio-pci devices are
+ * enumerated as though they are behind an IOMMU, but the virtio host
+ * ignores the IOMMU, so we must either pretend that the IOMMU isn't

Quoted 8 lines

drivers/virtio/virtio_ring.c line 45

Quoted 5 lines

drivers/virtio/virtio_ring.c +5 -0

+ * there or somehow map everything as the identity.
+ *
+ * For the time being, we preseve historic behavior and bypass the DMA
+ * API.
+ */

I spot at least three typos in there, FWIW. ('DMI API', 'sytems', 'preseve').

Good catch, hopefully will be fixed in v2.

Quoted 15 lines

drivers/virtio/virtio_ring.c line 51

Quoted 6 lines

drivers/virtio/virtio_ring.c +5 -0

+static bool vring_use_dma_api(void)
+{
+   return false;
+}
+

I'd quite like to see this be an explicit opt-out for the known-broken platforms. We've listed the SPARC and PPC64 issues. For x86 I need to refresh my memory as a prelude to trying to fix it... was the issue *just* that Qemu tends to ship with a broken BIOS that misdescribes the virtio devices (and any assigned PCI devices) as being behind an IOMMU when they're not, in the rare case that Qemu actually exposes its partially-implemented virtual IOMMU to the guest?

Quoted 3 lines

Could we have an arch_vring_eschew_dma_api(dev) function which the affected architectures could provide (as a prelude to fixing it so that the DMA API does the right thing for *itself*)?

I'm fine with this.

Quoted 33 lines · David Woodhouse

Quoted 32 lines · Andy Lutomirski

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

drivers/virtio/virtio_ring.c +13 -0

index e12e385f7ac3..4b8dab4960bb 100644
@@ -25,6 +25,30 @@
 #include
 #include
 
+/*
+ * The interaction between virtio and a possible IOMMU is a mess.
+ *
+ * On most systems with virtio, physical addresses match bus addresses,
+ * and it doesn't particularly matter whether we use the DMI API.
+ *
+ * On some sytems, including Xen and any system with a physical device
+ * that speaks virtio behind a physical IOMMU, we must use the DMA API
+ * for virtio DMA to work at all.
+ *
+ * On other systems, including SPARC and PPC64, virtio-pci devices are
+ * enumerated as though they are behind an IOMMU, but the virtio host
+ * ignores the IOMMU, so we must either pretend that the IOMMU isn't

Quoted 8 lines

drivers/virtio/virtio_ring.c line 45

Quoted 5 lines

drivers/virtio/virtio_ring.c +5 -0

+ * there or somehow map everything as the identity.
+ *
+ * For the time being, we preseve historic behavior and bypass the DMA
+ * API.
+ */

I spot at least three typos in there, FWIW. ('DMI API', 'sytems', 'preseve').

Good catch, hopefully will be fixed in v2.

Quoted 15 lines

drivers/virtio/virtio_ring.c line 51

Quoted 6 lines

drivers/virtio/virtio_ring.c +5 -0

+static bool vring_use_dma_api(void)
+{
+   return false;
+}
+

I'd quite like to see this be an explicit opt-out for the known-broken platforms. We've listed the SPARC and PPC64 issues. For x86 I need to refresh my memory as a prelude to trying to fix it... was the issue *just* that Qemu tends to ship with a broken BIOS that misdescribes the virtio devices (and any assigned PCI devices) as being behind an IOMMU when they're not, in the rare case that Qemu actually exposes its partially-implemented virtual IOMMU to the guest?

Quoted 3 lines

Could we have an arch_vring_eschew_dma_api(dev) function which the affected architectures could provide (as a prelude to fixing it so that the DMA API does the right thing for *itself*)?

I'm fine with this.

Quoted 32 lines · Andy Lutomirski

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++

 1 file changed, 24 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index e12e385f7ac3..4b8dab4960bb 100644
@@ -25,6 +25,30 @@
  #include 
  #include 

+/*
+ * The interaction between virtio and a possible IOMMU is a mess.
+ *
+ * On most systems with virtio, physical addresses match bus addresses,
+ * and it doesn't particularly matter whether we use the DMI API.
+ *
+ * On some sytems, including Xen and any system with a physical device
+ * that speaks virtio behind a physical IOMMU, we must use the DMA API
+ * for virtio DMA to work at all.
+ *
+ * On other systems, including SPARC and PPC64, virtio-pci devices are
+ * enumerated as though they are behind an IOMMU, but the virtio host
+ * ignores the IOMMU, so we must either pretend that the IOMMU isn't

Quoted 5 lines

+ * there or somehow map everything as the identity.
+ *
+ * For the time being, we preseve historic behavior and bypass the DMA
+ * API.
+ */

I spot at least three typos in there, FWIW. ('DMI API', 'sytems', 'preseve').

drivers/virtio/virtio_ring.c line 51

Quoted 5 lines

drivers/virtio/virtio_ring.c +5 -0

+static bool vring_use_dma_api(void)
+{
+	return false;
+}
+

I'd quite like to see this be an explicit opt-out for the known-broken platforms. We've listed the SPARC and PPC64 issues. For x86 I need to refresh my memory as a prelude to trying to fix it... was the issue *just* that Qemu tends to ship with a broken BIOS that misdescribes the virtio devices (and any assigned PCI devices) as being behind an IOMMU when they're not, in the rare case that Qemu actually exposes its partially-implemented virtual IOMMU to the guest?

Could we have an arch_vring_eschew_dma_api(dev) function which the affected architectures could provide (as a prelude to fixing it so that the DMA API does the right thing for *itself*)?

It would be functionally equivalent, but it would help to push the workarounds to the right place — rather than entrenching them for ever in tricky "OMG we need to audit what all the architectures do... let's not touch it!" code.

Signature · 2 lines

David Woodhouse                            Open Source Technology Centre
[email protected]                              Intel Corporation

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++

 1 file changed, 24 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index e12e385f7ac3..4b8dab4960bb 100644
@@ -25,6 +25,30 @@
  #include 
  #include 

+/*
+ * The interaction between virtio and a possible IOMMU is a mess.
+ *
+ * On most systems with virtio, physical addresses match bus addresses,
+ * and it doesn't particularly matter whether we use the DMI API.
+ *
+ * On some sytems, including Xen and any system with a physical device
+ * that speaks virtio behind a physical IOMMU, we must use the DMA API
+ * for virtio DMA to work at all.
+ *

+ * On other systems, including SPARC and PPC64, virtio-pci devices are
+ * enumerated as though they are behind an IOMMU, but the virtio host
+ * ignores the IOMMU, so we must either pretend that the IOMMU isn't
+ * there or somehow map everything as the identity.
+ *
+ * For the time being, we preseve historic behavior and bypass the DMA
+ * API.
+ */

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+	/*
+	 * In theory, it's possible to have a buggy QEMU-supposed
+	 * emulated Q35 IOMMU and Xen enabled at the same time.  On
+	 * such a configuration, virtio has never worked and will
+	 * not work without an even larger kludge.  Instead, enable
+	 * the DMA API if we're a Xen guest, which at least allows
+	 * all of the sensible Xen configurations to work correctly.
+	 */
+	return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+   /*
+    * In theory, it's possible to have a buggy QEMU-supposed
+    * emulated Q35 IOMMU and Xen enabled at the same time.  On
+    * such a configuration, virtio has never worked and will
+    * not work without an even larger kludge.  Instead, enable
+    * the DMA API if we're a Xen guest, which at least allows
+    * all of the sensible Xen configurations to work correctly.
+    */
+   return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

Quoted 31 lines · Michael S. Tsirkin

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+   /*
+    * In theory, it's possible to have a buggy QEMU-supposed
+    * emulated Q35 IOMMU and Xen enabled at the same time.  On
+    * such a configuration, virtio has never worked and will
+    * not work without an even larger kludge.  Instead, enable
+    * the DMA API if we're a Xen guest, which at least allows
+    * all of the sensible Xen configurations to work correctly.
+    */
+   return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 7 lines

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

They certainly can under nested virt (L0 provides virtio device, L1 is Xen, and L2 is Linux). Of course, this won't work given the current QEMU situation unless Xen can pass things through to dom0 without an IOMMU, which seems plausible to me.

But yes, xen_domain() sounds right to me. I just failed to find that function when I wrote this patch.

Michael, if you like the rest of the series, I'd be okay if you changed this patch to use xen_domain() when you apply it. If I send a v2, I'll fix it up.

--Andy

Quoted 52 lines · Andy Lutomirski

Quoted 31 lines · Michael S. Tsirkin

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+   /*
+    * In theory, it's possible to have a buggy QEMU-supposed
+    * emulated Q35 IOMMU and Xen enabled at the same time.  On
+    * such a configuration, virtio has never worked and will
+    * not work without an even larger kludge.  Instead, enable
+    * the DMA API if we're a Xen guest, which at least allows
+    * all of the sensible Xen configurations to work correctly.
+    */
+   return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 7 lines

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

They certainly can under nested virt (L0 provides virtio device, L1 is Xen, and L2 is Linux). Of course, this won't work given the current QEMU situation unless Xen can pass things through to dom0 without an IOMMU, which seems plausible to me.

But yes, xen_domain() sounds right to me. I just failed to find that function when I wrote this patch.

Michael, if you like the rest of the series, I'd be okay if you changed this patch to use xen_domain() when you apply it. If I send a v2, I'll fix it up.

Quoted 1 line

--Andy

I'd rather you just posted a tested v2 of 9/10 for now as I don't test Xen. It seems easy but I had more than my share of obvious fixes failing spectacularly.

Quoted 52 lines · Andy Lutomirski

Quoted 31 lines · Michael S. Tsirkin

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+   /*
+    * In theory, it's possible to have a buggy QEMU-supposed
+    * emulated Q35 IOMMU and Xen enabled at the same time.  On
+    * such a configuration, virtio has never worked and will
+    * not work without an even larger kludge.  Instead, enable
+    * the DMA API if we're a Xen guest, which at least allows
+    * all of the sensible Xen configurations to work correctly.
+    */
+   return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 7 lines

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

They certainly can under nested virt (L0 provides virtio device, L1 is Xen, and L2 is Linux). Of course, this won't work given the current QEMU situation unless Xen can pass things through to dom0 without an IOMMU, which seems plausible to me.

But yes, xen_domain() sounds right to me. I just failed to find that function when I wrote this patch.

Michael, if you like the rest of the series, I'd be okay if you changed this patch to use xen_domain() when you apply it. If I send a v2, I'll fix it up.

Quoted 1 line

--Andy

I'd rather you just posted a tested v2 of 9/10 for now as I don't test Xen. It seems easy but I had more than my share of obvious fixes failing spectacularly.

Quoted 52 lines · Andy Lutomirski

Quoted 31 lines · Michael S. Tsirkin

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+   /*
+    * In theory, it's possible to have a buggy QEMU-supposed
+    * emulated Q35 IOMMU and Xen enabled at the same time.  On
+    * such a configuration, virtio has never worked and will
+    * not work without an even larger kludge.  Instead, enable
+    * the DMA API if we're a Xen guest, which at least allows
+    * all of the sensible Xen configurations to work correctly.
+    */
+   return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 7 lines

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

They certainly can under nested virt (L0 provides virtio device, L1 is Xen, and L2 is Linux). Of course, this won't work given the current QEMU situation unless Xen can pass things through to dom0 without an IOMMU, which seems plausible to me.

But yes, xen_domain() sounds right to me. I just failed to find that function when I wrote this patch.

Michael, if you like the rest of the series, I'd be okay if you changed this patch to use xen_domain() when you apply it. If I send a v2, I'll fix it up.

Quoted 1 line

--Andy

I'd rather you just posted a tested v2 of 9/10 for now as I don't test Xen. It seems easy but I had more than my share of obvious fixes failing spectacularly.

Quoted 31 lines · Michael S. Tsirkin

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+   /*
+    * In theory, it's possible to have a buggy QEMU-supposed
+    * emulated Q35 IOMMU and Xen enabled at the same time.  On
+    * such a configuration, virtio has never worked and will
+    * not work without an even larger kludge.  Instead, enable
+    * the DMA API if we're a Xen guest, which at least allows
+    * all of the sensible Xen configurations to work correctly.
+    */
+   return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 7 lines

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

They certainly can under nested virt (L0 provides virtio device, L1 is Xen, and L2 is Linux). Of course, this won't work given the current QEMU situation unless Xen can pass things through to dom0 without an IOMMU, which seems plausible to me.

But yes, xen_domain() sounds right to me. I just failed to find that function when I wrote this patch.

Michael, if you like the rest of the series, I'd be okay if you changed this patch to use xen_domain() when you apply it. If I send a v2, I'll fix it up.

--Andy

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+   /*
+    * In theory, it's possible to have a buggy QEMU-supposed
+    * emulated Q35 IOMMU and Xen enabled at the same time.  On
+    * such a configuration, virtio has never worked and will
+    * not work without an even larger kludge.  Instead, enable
+    * the DMA API if we're a Xen guest, which at least allows
+    * all of the sensible Xen configurations to work correctly.
+    */
+   return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+	/*
+	 * In theory, it's possible to have a buggy QEMU-supposed
+	 * emulated Q35 IOMMU and Xen enabled at the same time.  On
+	 * such a configuration, virtio has never worked and will
+	 * not work without an even larger kludge.  Instead, enable
+	 * the DMA API if we're a Xen guest, which at least allows
+	 * all of the sensible Xen configurations to work correctly.
+	 */
+	return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

Signature · 6 lines

MST

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 30 lines · David Vrabel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+	/*
+	 * In theory, it's possible to have a buggy QEMU-supposed
+	 * emulated Q35 IOMMU and Xen enabled at the same time.  On
+	 * such a configuration, virtio has never worked and will
+	 * not work without an even larger kludge.  Instead, enable
+	 * the DMA API if we're a Xen guest, which at least allows
+	 * all of the sensible Xen configurations to work correctly.
+	 */
+	return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Quoted 4 lines

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

I doubt HVM domains can have virtio devices.

Signature · 6 lines

MST

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Quoted 13 lines · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

drivers/virtio/virtio_ring.c line 59

Quoted 10 lines

drivers/virtio/virtio_ring.c +10 -0

+#if defined(CONFIG_X86) && defined(CONFIG_XEN)
+	/*
+	 * In theory, it's possible to have a buggy QEMU-supposed
+	 * emulated Q35 IOMMU and Xen enabled at the same time.  On
+	 * such a configuration, virtio has never worked and will
+	 * not work without an even larger kludge.  Instead, enable
+	 * the DMA API if we're a Xen guest, which at least allows
+	 * all of the sensible Xen configurations to work correctly.
+	 */
+	return static_cpu_has(X86_FEATURE_XENPV);

You want:

    if (xen_domain())
        return true;

Without the #if so we use the DMA API for all types of Xen guest on all architectures.

David

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/virtio/virtio_ring.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/virtio/virtio_ring.c +0 -0

index c169c6444637..305c05cc249a 100644
@@ -47,6 +47,18 @@
 
 static bool vring_use_dma_api(void)
 {

To everyone else: we've waffled on this for way too long.  I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

Also, wasn't Christoph looking at making per-device DMA ops more generic instead of an 'archdata' thing on basically every platform? Or did I just imagine that part?

Also, wasn't Christoph looking at making per-device DMA ops more generic instead of an 'archdata' thing on basically every platform? Or did I just imagine that part?

To everyone else: we've waffled on this for way too long.  I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

To everyone else: we've waffled on this for way too long.  I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it?

To everyone else: we've waffled on this for way too long. I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

Michael, if these survive review, can you stage these in your tree?

Can you also take a look at tools/virtio? I probably broke it, but I couldn't get it to build without these patches either, so I'm stuck.

Changes from v4:
- Bake vring_use_dma_api in from the beginning.
- Automatically enable only on Xen.
- Add module parameter.
- Add s390 and alpha DMA API implementations.
- Rebase to 4.5-rc1.

Changes from v3:
- More big-endian fixes.
- Added better virtio-ring APIs that handle allocation and use them in virtio-mmio and virtio-pci.
- Switch to Michael's virtio-net patch.

Changes from v2:
- Fix vring_mapping_error incorrect argument

Changes from v1:
- Fix an endian conversion error causing a BUG to hit.
- Fix a DMA ordering issue (swiotlb=force works now).
- Minor cleanups.

Andy Lutomirski (7):
vring: Introduce vring_use_dma_api()
virtio_ring: Support DMA APIs
virtio: Add improved queue allocation API
virtio_mmio: Use the DMA API if enabled
virtio_pci: Use the DMA API if enabled
vring: Use the DMA API on Xen
vring: Add a module parameter to force-enable the DMA API

Christian Borntraeger (3):
dma: Provide simple noop dma ops
alpha/dma: use common noop dma ops
s390/dma: Allow per device dma ops

 arch/alpha/kernel/pci-noop.c        |  46 +---
 arch/s390/Kconfig                   |   6 +-
 arch/s390/include/asm/device.h      |   6 +-
 arch/s390/include/asm/dma-mapping.h |   6 +-
 arch/s390/pci/pci.c                 |   1 +
 arch/s390/pci/pci_dma.c             |   4 +-
 drivers/virtio/Kconfig              |   2 +-
 drivers/virtio/virtio_mmio.c        |  67 ++----
 drivers/virtio/virtio_pci_common.h  |   6 -
 drivers/virtio/virtio_pci_legacy.c  |  42 ++--
 drivers/virtio/virtio_pci_modern.c  |  61 ++----
 drivers/virtio/virtio_ring.c        | 412 ++++++++++++++++++++++++++++++------
 include/linux/dma-mapping.h         |   2 +
 include/linux/virtio.h              |  23 +-
 include/linux/virtio_ring.h         |  35 +++
 lib/Makefile                        |   1 +
 lib/dma-noop.c                      |  75 +++++++
 tools/virtio/linux/dma-mapping.h    |  17 ++
 18 files changed, 568 insertions(+), 244 deletions(-)
 create mode 100644 lib/dma-noop.c
 create mode 100644 tools/virtio/linux/dma-mapping.h

Signature · 1 line

2.5.0

Quoted 6 lines · Andy Lutomirski

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

Quoted 7 lines

To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it?

To everyone else: we've waffled on this for way too long. I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

I agree, thanks for working on this!

Quoted 1 line

Michael, if these survive review, can you stage these in your tree?

Yes, I'll stage everything except 10/10. I'd rather not maintain a module option like this, things work for now and I'm working on a clean solution for things like dpdk within guest.

Quoted 6 lines · Andy Lutomirski

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

Quoted 7 lines

To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it?

To everyone else: we've waffled on this for way too long. I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

I agree, thanks for working on this!

Quoted 1 line

Michael, if these survive review, can you stage these in your tree?

Yes, I'll stage everything except 10/10. I'd rather not maintain a module option like this, things work for now and I'm working on a clean solution for things like dpdk within guest.

Quoted 6 lines · Andy Lutomirski

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

Quoted 7 lines

To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it?

To everyone else: we've waffled on this for way too long. I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

I agree, thanks for working on this!

Quoted 1 line

Michael, if these survive review, can you stage these in your tree?

Yes, I'll stage everything except 10/10. I'd rather not maintain a module option like this, things work for now and I'm working on a clean solution for things like dpdk within guest.

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it?

To everyone else: we've waffled on this for way too long. I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

Michael, if these survive review, can you stage these in your tree?

Can you also take a look at tools/virtio? I probably broke it, but I couldn't get it to build without these patches either, so I'm stuck.

Changes from v4:
- Bake vring_use_dma_api in from the beginning.
- Automatically enable only on Xen.
- Add module parameter.
- Add s390 and alpha DMA API implementations.
- Rebase to 4.5-rc1.

Changes from v3:
- More big-endian fixes.
- Added better virtio-ring APIs that handle allocation and use them in virtio-mmio and virtio-pci.
- Switch to Michael's virtio-net patch.

Changes from v2:
- Fix vring_mapping_error incorrect argument

Changes from v1:
- Fix an endian conversion error causing a BUG to hit.
- Fix a DMA ordering issue (swiotlb=force works now).
- Minor cleanups.

Andy Lutomirski (7):
vring: Introduce vring_use_dma_api()
virtio_ring: Support DMA APIs
virtio: Add improved queue allocation API
virtio_mmio: Use the DMA API if enabled
virtio_pci: Use the DMA API if enabled
vring: Use the DMA API on Xen
vring: Add a module parameter to force-enable the DMA API

Christian Borntraeger (3):
dma: Provide simple noop dma ops
alpha/dma: use common noop dma ops
s390/dma: Allow per device dma ops

 arch/alpha/kernel/pci-noop.c        |  46 +---
 arch/s390/Kconfig                   |   6 +-
 arch/s390/include/asm/device.h      |   6 +-
 arch/s390/include/asm/dma-mapping.h |   6 +-
 arch/s390/pci/pci.c                 |   1 +
 arch/s390/pci/pci_dma.c             |   4 +-
 drivers/virtio/Kconfig              |   2 +-
 drivers/virtio/virtio_mmio.c        |  67 ++----
 drivers/virtio/virtio_pci_common.h  |   6 -
 drivers/virtio/virtio_pci_legacy.c  |  42 ++--
 drivers/virtio/virtio_pci_modern.c  |  61 ++----
 drivers/virtio/virtio_ring.c        | 412 ++++++++++++++++++++++++++++++------
 include/linux/dma-mapping.h         |   2 +
 include/linux/virtio.h              |  23 +-
 include/linux/virtio_ring.h         |  35 +++
 lib/Makefile                        |   1 +
 lib/dma-noop.c                      |  75 +++++++
 tools/virtio/linux/dma-mapping.h    |  17 ++
 18 files changed, 568 insertions(+), 244 deletions(-)
 create mode 100644 lib/dma-noop.c
 create mode 100644 tools/virtio/linux/dma-mapping.h

Signature · 1 line

2.5.0

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it?

To everyone else: we've waffled on this for way too long. I think we should to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around.

Michael, if these survive review, can you stage these in your tree?

Can you also take a look at tools/virtio? I probably broke it, but I couldn't get it to build without these patches either, so I'm stuck.

Changes from v4:
- Bake vring_use_dma_api in from the beginning.
- Automatically enable only on Xen.
- Add module parameter.
- Add s390 and alpha DMA API implementations.
- Rebase to 4.5-rc1.

Changes from v3:
- More big-endian fixes.
- Added better virtio-ring APIs that handle allocation and use them in virtio-mmio and virtio-pci.
- Switch to Michael's virtio-net patch.

Changes from v2:
- Fix vring_mapping_error incorrect argument

Changes from v1:
- Fix an endian conversion error causing a BUG to hit.
- Fix a DMA ordering issue (swiotlb=force works now).
- Minor cleanups.

Andy Lutomirski (7):
vring: Introduce vring_use_dma_api()
virtio_ring: Support DMA APIs
virtio: Add improved queue allocation API
virtio_mmio: Use the DMA API if enabled
virtio_pci: Use the DMA API if enabled
vring: Use the DMA API on Xen
vring: Add a module parameter to force-enable the DMA API

Christian Borntraeger (3):
dma: Provide simple noop dma ops
alpha/dma: use common noop dma ops
s390/dma: Allow per device dma ops

 arch/alpha/kernel/pci-noop.c        |  46 +---
 arch/s390/Kconfig                   |   6 +-
 arch/s390/include/asm/device.h      |   6 +-
 arch/s390/include/asm/dma-mapping.h |   6 +-
 arch/s390/pci/pci.c                 |   1 +
 arch/s390/pci/pci_dma.c             |   4 +-
 drivers/virtio/Kconfig              |   2 +-
 drivers/virtio/virtio_mmio.c        |  67 ++----
 drivers/virtio/virtio_pci_common.h  |   6 -
 drivers/virtio/virtio_pci_legacy.c  |  42 ++--
 drivers/virtio/virtio_pci_modern.c  |  61 ++----
 drivers/virtio/virtio_ring.c        | 412 ++++++++++++++++++++++++++++++------
 include/linux/dma-mapping.h         |   2 +
 include/linux/virtio.h              |  23 +-
 include/linux/virtio_ring.h         |  35 +++
 lib/Makefile                        |   1 +
 lib/dma-noop.c                      |  75 +++++++
 tools/virtio/linux/dma-mapping.h    |  17 ++
 18 files changed, 568 insertions(+), 244 deletions(-)
 create mode 100644 lib/dma-noop.c
 create mode 100644 tools/virtio/linux/dma-mapping.h

Signature · 1 line

2.5.0

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

Nice work, Andy.

Quoted 3 lines · Andy Lutomirski

This switches virtio to use the DMA API on Xen and if requested by module option.

Quoted 3 lines

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

What is your setup? My understanding is that virtio doesn't work on PV guest as of now because a suitable transport is missing.

Quoted 10 lines · Wei Liu

Nice work, Andy.

Quoted 6 lines · Andy Lutomirski

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

Quoted 2 lines

What is your setup? My understanding is that virtio doesn't work on PV guest as of now because a suitable transport is missing.

I cheated and ran Xen under KVM with the virtio-pci device provided by
QEMU. If you have virtme
(https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/), you can do:

virtme-run --kdir=. --pwd --xen xen-4.5.2 --qemu-opts -smp 3 -m 1024

where xen-4.5.2 is the gunzipped Xen binary. (Other versions work, too.)

--Andy

Quoted 10 lines · Wei Liu

Nice work, Andy.

Quoted 6 lines · Andy Lutomirski

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

Quoted 2 lines

What is your setup? My understanding is that virtio doesn't work on PV guest as of now because a suitable transport is missing.

I cheated and ran Xen under KVM with the virtio-pci device provided by
QEMU. If you have virtme
(https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/), you can do:

virtme-run --kdir=. --pwd --xen xen-4.5.2 --qemu-opts -smp 3 -m 1024

where xen-4.5.2 is the gunzipped Xen binary. (Other versions work, too.)

--Andy

Nice work, Andy.

Quoted 3 lines · Andy Lutomirski

This switches virtio to use the DMA API on Xen and if requested by module option.

Quoted 3 lines

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.

What is your setup? My understanding is that virtio doesn't work on PV guest as of now because a suitable transport is missing.

This switches virtio to use the DMA API on Xen and if requested by module option.

This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86.