similar to: [PATCH v2 0/2] vfio: blacklist legacy virtio devices

On Tue, 30 Aug 2016 05:27:17 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is enabled. > > Signed-off-by: Michael S.

On Tue, 30 Aug 2016 05:27:17 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is enabled. > > Signed-off-by: Michael S.

On Mon, 29 Aug 2016 21:52:20 -0600 Alex Williamson <alex.williamson at redhat.com> wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson <alex.williamson at redhat.com> wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > > > Modern virtio pci devices can set

On Mon, 29 Aug 2016 21:52:20 -0600 Alex Williamson <alex.williamson at redhat.com> wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson <alex.williamson at redhat.com> wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > > > Modern virtio pci devices can set

This is an attempt to allow enabling IOMMU for DMA. Design: - new feature bit IOMMU_PLATFORM which means host won't bypass IOMMU - virtio core uses DMA API if it sees IOMMU_PLATFORM - add quirk for vfio to disable device unless IOMMU_PLATFORM is set or the no-iommu mode is enabled - while I'm not sure how it will be used, it seems like a good idea to also have

This is an attempt to allow enabling IOMMU for DMA. Design: - new feature bit IOMMU_PLATFORM which means host won't bypass IOMMU - virtio core uses DMA API if it sees IOMMU_PLATFORM - add quirk for vfio to disable device unless IOMMU_PLATFORM is set or the no-iommu mode is enabled - while I'm not sure how it will be used, it seems like a good idea to also have

On Mon, 18 Apr 2016 12:58:28 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is enabled. > > Signed-off-by: Michael S.

On Mon, 18 Apr 2016 12:58:28 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is enabled. > > Signed-off-by: Michael S.

Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM to signal they are safe to use with an IOMMU. Without this bit, exposing the device to userspace is unsafe, so probe and fail VFIO initialization unless noiommu is enabled. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vfio/pci/vfio_pci_private.h | 1 + drivers/vfio/pci/vfio_pci.c | 14 ++++

On Mon, Aug 29, 2016 at 10:53:04PM -0600, Alex Williamson wrote: > On Mon, 29 Aug 2016 21:52:20 -0600 > Alex Williamson <alex.williamson at redhat.com> wrote: > > > On Mon, 29 Aug 2016 21:23:25 -0600 > > Alex Williamson <alex.williamson at redhat.com> wrote: > > > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > > "Michael S. Tsirkin"

On Mon, 29 Aug 2016 21:23:25 -0600 Alex Williamson <alex.williamson at redhat.com> wrote: > On Tue, 30 Aug 2016 05:27:17 +0300 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > > to signal they are safe to use with an IOMMU. > > > > Without this bit, exposing the device to

Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM to signal they are safe to use with an IOMMU. Without this bit, exposing the device to userspace is unsafe, so probe and fail VFIO initialization unless noiommu is enabled. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vfio/pci/vfio_pci_private.h | 1 + drivers/vfio/pci/vfio_pci.c | 11 +++

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual. Correctable errors are not reported to guest at all.

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual. Correctable errors are not reported to guest at all.

Hi Alex, I've been playing around with VFIO and megasas (of course). What I did now was switching between VFIO and 'normal' operation, ie emulated access. megasas is happily running under VFIO, but when I do an emergency stop like killing the Qemu session the PCI device is not properly reset. IE when I load 'megaraid_sas' after unbinding the vfio_pci module the driver

Hi Alex, I've been playing around with VFIO and megasas (of course). What I did now was switching between VFIO and 'normal' operation, ie emulated access. megasas is happily running under VFIO, but when I do an emergency stop like killing the Qemu session the PCI device is not properly reset. IE when I load 'megaraid_sas' after unbinding the vfio_pci module the driver

On 2016?08?30? 10:27, Michael S. Tsirkin wrote: > Legacy virtio devices always bypassed an IOMMU, so using them with vfio was > never safe. And it actually won't work since GPA is assumed in the device. So I'm not sure this is must since we should get a IOMMU fault in this case. > This adds a quirk detecting these and disabling VFIO unless the > noiommu mode is used. At

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual. Correctable errors are not reported to guest at all.

This is a design and an initial patch for kernel side for AER support in VFIO. 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual. Correctable errors are not reported to guest at all.

Good morning, there is a typo in my description; the line <address domain='0x0' bus='0x1' slot='0x00' function='0x0'/> should be <address domain='0x0' bus='0x2' slot='0x00' function='0x0'/> That was correct in my xml-file. Isn't there anybody how can help me with that? Regards Michael Weis Von: