| Message ID | 64e979cc139c5e6a9bbfae9f1bc5e6693d91bea9.1454034075.git.luto@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 29/01/16 02:31, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski <luto@kernel.org> > --- > drivers/virtio/virtio_ring.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > index c169c6444637..305c05cc249a 100644 > --- a/drivers/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -47,6 +47,18 @@ > > static bool vring_use_dma_api(void) > { > +#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
On Fri, Jan 29, 2016 at 10:34:59AM +0000, David Vrabel wrote: > On 29/01/16 02:31, Andy Lutomirski wrote: > > Signed-off-by: Andy Lutomirski <luto@kernel.org> > > --- > > drivers/virtio/virtio_ring.c | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index c169c6444637..305c05cc249a 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -47,6 +47,18 @@ > > > > static bool vring_use_dma_api(void) > > { > > +#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 I doubt HVM domains can have virtio devices.
On Sun, Jan 31, 2016 at 12:09 PM, Michael S. Tsirkin <mst@redhat.com> wrote: > On Fri, Jan 29, 2016 at 10:34:59AM +0000, David Vrabel wrote: >> On 29/01/16 02:31, Andy Lutomirski wrote: >> > Signed-off-by: Andy Lutomirski <luto@kernel.org> >> > --- >> > drivers/virtio/virtio_ring.c | 12 ++++++++++++ >> > 1 file changed, 12 insertions(+) >> > >> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c >> > index c169c6444637..305c05cc249a 100644 >> > --- a/drivers/virtio/virtio_ring.c >> > +++ b/drivers/virtio/virtio_ring.c >> > @@ -47,6 +47,18 @@ >> > >> > static bool vring_use_dma_api(void) >> > { >> > +#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 > > 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
On Sun, Jan 31, 2016 at 12:13:58PM -0800, Andy Lutomirski wrote: > On Sun, Jan 31, 2016 at 12:09 PM, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, Jan 29, 2016 at 10:34:59AM +0000, David Vrabel wrote: > >> On 29/01/16 02:31, Andy Lutomirski wrote: > >> > Signed-off-by: Andy Lutomirski <luto@kernel.org> > >> > --- > >> > drivers/virtio/virtio_ring.c | 12 ++++++++++++ > >> > 1 file changed, 12 insertions(+) > >> > > >> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > >> > index c169c6444637..305c05cc249a 100644 > >> > --- a/drivers/virtio/virtio_ring.c > >> > +++ b/drivers/virtio/virtio_ring.c > >> > @@ -47,6 +47,18 @@ > >> > > >> > static bool vring_use_dma_api(void) > >> > { > >> > +#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 > > > > 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 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.
On Sun, Jan 31, 2016 at 12:18 PM, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Jan 31, 2016 at 12:13:58PM -0800, Andy Lutomirski wrote: >> On Sun, Jan 31, 2016 at 12:09 PM, Michael S. Tsirkin <mst@redhat.com> wrote: >> > On Fri, Jan 29, 2016 at 10:34:59AM +0000, David Vrabel wrote: >> >> On 29/01/16 02:31, Andy Lutomirski wrote: >> >> > Signed-off-by: Andy Lutomirski <luto@kernel.org> >> >> > --- >> >> > drivers/virtio/virtio_ring.c | 12 ++++++++++++ >> >> > 1 file changed, 12 insertions(+) >> >> > >> >> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c >> >> > index c169c6444637..305c05cc249a 100644 >> >> > --- a/drivers/virtio/virtio_ring.c >> >> > +++ b/drivers/virtio/virtio_ring.c >> >> > @@ -47,6 +47,18 @@ >> >> > >> >> > static bool vring_use_dma_api(void) >> >> > { >> >> > +#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 >> > >> > 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 > > 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. > In that case, let me test for real. Can you point me to a git tree when you have patches 1-8 staged and I'll spin patch 9 v2 and test it with the real context? --Andy
On Sun, Jan 31, 2016 at 10:09:07PM +0200, Michael S. Tsirkin wrote: > On Fri, Jan 29, 2016 at 10:34:59AM +0000, David Vrabel wrote: > > On 29/01/16 02:31, Andy Lutomirski wrote: > > > Signed-off-by: Andy Lutomirski <luto@kernel.org> > > > --- > > > drivers/virtio/virtio_ring.c | 12 ++++++++++++ > > > 1 file changed, 12 insertions(+) > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > index c169c6444637..305c05cc249a 100644 > > > --- a/drivers/virtio/virtio_ring.c > > > +++ b/drivers/virtio/virtio_ring.c > > > @@ -47,6 +47,18 @@ > > > > > > static bool vring_use_dma_api(void) > > > { > > > +#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 > > I doubt HVM domains can have virtio devices. > Yes, they can. When virtio-pci is used virtio device is just yet another pci device emulated by QEMU. Wei. > -- > MST > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index c169c6444637..305c05cc249a 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -47,6 +47,18 @@ static bool vring_use_dma_api(void) { +#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); +#endif + return false; }
Signed-off-by: Andy Lutomirski <luto@kernel.org> --- drivers/virtio/virtio_ring.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)