From: Peter Xu <peterx@redhat.com> To: qemu-devel@nongnu.org Cc: "Daniel P. Berrangé" <berrange@redhat.com>, "Eduardo Habkost" <ehabkost@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, "Jason Wang" <jasowang@redhat.com>, "Alex Williamson" <alex.williamson@redhat.com>, peterx@redhat.com, "Eric Auger" <eric.auger@redhat.com>, "Bandan Das" <bsd@redhat.com>, "Igor Mammedov" <imammedo@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Richard Henderson" <rth@twiddle.net> Subject: [Qemu-devel] [PATCH v3 1/4] intel_iommu: Sanity check vfio-pci config on machine init done Date: Mon, 16 Sep 2019 16:07:15 +0800 [thread overview] Message-ID: <20190916080718.3299-2-peterx@redhat.com> (raw) In-Reply-To: <20190916080718.3299-1-peterx@redhat.com> This check was previously only happened when the IOMMU is enabled in the guest. It was always too late because the enabling of IOMMU normally only happens during the boot of guest OS. It means that we can bail out and exit directly during the guest OS boots if the configuration of devices are not supported. Or, if the guest didn't enable vIOMMU at all, then the user can use the guest normally but as long as it reconfigure the guest OS to enable the vIOMMU then reboot, the user will see the panic right after the reset when the next boot starts. Let's make this failure even earlier so that we force the user to use caching-mode for vfio-pci devices when with the vIOMMU. So the user won't get surprise at least during execution of the guest, which seems a bit nicer. This will affect some user who didn't enable vIOMMU in the guest OS but was using vfio-pci and the vtd device in the past. However I hope it's not a majority because not enabling vIOMMU with the device attached is actually meaningless. We still keep the old assertion for safety so far because the hotplug path could still reach it, so far. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> --- hw/i386/intel_iommu.c | 39 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 36 insertions(+), 3 deletions(-) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 75ca6f9c70..bed8ffe446 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -35,6 +35,7 @@ #include "hw/i386/x86-iommu.h" #include "hw/pci-host/q35.h" #include "sysemu/kvm.h" +#include "sysemu/sysemu.h" #include "hw/i386/apic_internal.h" #include "kvm_i386.h" #include "migration/vmstate.h" @@ -64,6 +65,13 @@ static void vtd_address_space_refresh_all(IntelIOMMUState *s); static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n); +static void vtd_panic_require_caching_mode(void) +{ + error_report("We need to set caching-mode=on for intel-iommu to enable " + "device assignment with IOMMU protection."); + exit(1); +} + static void vtd_define_quad(IntelIOMMUState *s, hwaddr addr, uint64_t val, uint64_t wmask, uint64_t w1cmask) { @@ -2929,9 +2937,7 @@ static void vtd_iommu_notify_flag_changed(IOMMUMemoryRegion *iommu, IntelIOMMUState *s = vtd_as->iommu_state; if (!s->caching_mode && new & IOMMU_NOTIFIER_MAP) { - error_report("We need to set caching-mode=on for intel-iommu to enable " - "device assignment with IOMMU protection."); - exit(1); + vtd_panic_require_caching_mode(); } /* Update per-address-space notifier flags */ @@ -3699,6 +3705,32 @@ static bool vtd_decide_config(IntelIOMMUState *s, Error **errp) return true; } +static int vtd_machine_done_notify_one(Object *child, void *unused) +{ + IntelIOMMUState *iommu = INTEL_IOMMU_DEVICE(x86_iommu_get_default()); + + /* + * We hard-coded here because vfio-pci is the only special case + * here. Let's be more elegant in the future when we can, but so + * far there seems to be no better way. + */ + if (object_dynamic_cast(child, "vfio-pci") && !iommu->caching_mode) { + vtd_panic_require_caching_mode(); + } + + return 0; +} + +static void vtd_machine_done_hook(Notifier *notifier, void *unused) +{ + object_child_foreach_recursive(object_get_root(), + vtd_machine_done_notify_one, NULL); +} + +static Notifier vtd_machine_done_notify = { + .notify = vtd_machine_done_hook, +}; + static void vtd_realize(DeviceState *dev, Error **errp) { MachineState *ms = MACHINE(qdev_get_machine()); @@ -3744,6 +3776,7 @@ static void vtd_realize(DeviceState *dev, Error **errp) pci_setup_iommu(bus, vtd_host_dma_iommu, dev); /* Pseudo address space under root PCI bus. */ pcms->ioapic_as = vtd_host_dma_iommu(bus, s, Q35_PSEUDO_DEVFN_IOAPIC); + qemu_add_machine_init_done_notifier(&vtd_machine_done_notify); } static void vtd_class_init(ObjectClass *klass, void *data) -- 2.21.0
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com> To: qemu-devel@nongnu.org Cc: Peter Maydell <peter.maydell@linaro.org>, Eduardo Habkost <ehabkost@redhat.com>, Peter Xu <peterx@redhat.com>, Eric Auger <eric.auger@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <rth@twiddle.net> Subject: [Qemu-devel] [PULL 05/10] intel_iommu: Sanity check vfio-pci config on machine init done Date: Tue, 17 Sep 2019 11:10:54 -0400 [thread overview] Message-ID: <20190916080718.3299-2-peterx@redhat.com> (raw) Message-ID: <20190917151054.uN5KONI5LRBeNINGNAVTOXpQijvmweDwNJVuPSxxiTY@z> (raw) In-Reply-To: <20190917151011.24588-1-mst@redhat.com> From: Peter Xu <peterx@redhat.com> This check was previously only happened when the IOMMU is enabled in the guest. It was always too late because the enabling of IOMMU normally only happens during the boot of guest OS. It means that we can bail out and exit directly during the guest OS boots if the configuration of devices are not supported. Or, if the guest didn't enable vIOMMU at all, then the user can use the guest normally but as long as it reconfigure the guest OS to enable the vIOMMU then reboot, the user will see the panic right after the reset when the next boot starts. Let's make this failure even earlier so that we force the user to use caching-mode for vfio-pci devices when with the vIOMMU. So the user won't get surprise at least during execution of the guest, which seems a bit nicer. This will affect some user who didn't enable vIOMMU in the guest OS but was using vfio-pci and the vtd device in the past. However I hope it's not a majority because not enabling vIOMMU with the device attached is actually meaningless. We still keep the old assertion for safety so far because the hotplug path could still reach it, so far. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20190916080718.3299-2-peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> --- hw/i386/intel_iommu.c | 39 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 36 insertions(+), 3 deletions(-) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 75ca6f9c70..bed8ffe446 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -35,6 +35,7 @@ #include "hw/i386/x86-iommu.h" #include "hw/pci-host/q35.h" #include "sysemu/kvm.h" +#include "sysemu/sysemu.h" #include "hw/i386/apic_internal.h" #include "kvm_i386.h" #include "migration/vmstate.h" @@ -64,6 +65,13 @@ static void vtd_address_space_refresh_all(IntelIOMMUState *s); static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n); +static void vtd_panic_require_caching_mode(void) +{ + error_report("We need to set caching-mode=on for intel-iommu to enable " + "device assignment with IOMMU protection."); + exit(1); +} + static void vtd_define_quad(IntelIOMMUState *s, hwaddr addr, uint64_t val, uint64_t wmask, uint64_t w1cmask) { @@ -2929,9 +2937,7 @@ static void vtd_iommu_notify_flag_changed(IOMMUMemoryRegion *iommu, IntelIOMMUState *s = vtd_as->iommu_state; if (!s->caching_mode && new & IOMMU_NOTIFIER_MAP) { - error_report("We need to set caching-mode=on for intel-iommu to enable " - "device assignment with IOMMU protection."); - exit(1); + vtd_panic_require_caching_mode(); } /* Update per-address-space notifier flags */ @@ -3699,6 +3705,32 @@ static bool vtd_decide_config(IntelIOMMUState *s, Error **errp) return true; } +static int vtd_machine_done_notify_one(Object *child, void *unused) +{ + IntelIOMMUState *iommu = INTEL_IOMMU_DEVICE(x86_iommu_get_default()); + + /* + * We hard-coded here because vfio-pci is the only special case + * here. Let's be more elegant in the future when we can, but so + * far there seems to be no better way. + */ + if (object_dynamic_cast(child, "vfio-pci") && !iommu->caching_mode) { + vtd_panic_require_caching_mode(); + } + + return 0; +} + +static void vtd_machine_done_hook(Notifier *notifier, void *unused) +{ + object_child_foreach_recursive(object_get_root(), + vtd_machine_done_notify_one, NULL); +} + +static Notifier vtd_machine_done_notify = { + .notify = vtd_machine_done_hook, +}; + static void vtd_realize(DeviceState *dev, Error **errp) { MachineState *ms = MACHINE(qdev_get_machine()); @@ -3744,6 +3776,7 @@ static void vtd_realize(DeviceState *dev, Error **errp) pci_setup_iommu(bus, vtd_host_dma_iommu, dev); /* Pseudo address space under root PCI bus. */ pcms->ioapic_as = vtd_host_dma_iommu(bus, s, Q35_PSEUDO_DEVFN_IOAPIC); + qemu_add_machine_init_done_notifier(&vtd_machine_done_notify); } static void vtd_class_init(ObjectClass *klass, void *data) -- MST
next prev parent reply other threads:[~2019-09-16 8:08 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-16 8:07 [Qemu-devel] [PATCH v3 0/4] intel_iommu: Do sanity check of vfio-pci earlier Peter Xu 2019-09-16 8:07 ` Peter Xu [this message] 2019-09-17 15:10 ` [Qemu-devel] [PULL 05/10] intel_iommu: Sanity check vfio-pci config on machine init done Michael S. Tsirkin 2019-09-16 8:07 ` [Qemu-devel] [PATCH v3 2/4] qdev/machine: Introduce hotplug_allowed hook Peter Xu 2019-09-17 15:10 ` [Qemu-devel] [PULL 06/10] " Michael S. Tsirkin 2019-09-16 8:07 ` [Qemu-devel] [PATCH v3 3/4] pc/q35: Disallow vfio-pci hotplug without VT-d caching mode Peter Xu 2019-09-17 15:11 ` [Qemu-devel] [PULL 07/10] " Michael S. Tsirkin 2019-09-16 8:07 ` [Qemu-devel] [PATCH v3 4/4] intel_iommu: Remove the caching-mode check during flag change Peter Xu 2019-09-17 15:11 ` [Qemu-devel] [PULL 08/10] " Michael S. Tsirkin -- strict thread matches above, loose matches on Subject: below -- 2019-09-17 15:10 [Qemu-devel] [PULL 00/10] virtio, vhost, pc: features, fixes, cleanups Michael S. Tsirkin 2019-08-01 0:40 ` [Qemu-devel] [PATCH v2] docs/nvdimm: add example on persistent backend setup Wei Yang 2019-08-01 8:05 ` Stefan Hajnoczi 2019-09-11 8:51 ` Wei Yang 2019-09-12 12:16 ` Stefan Hajnoczi 2019-09-12 21:44 ` Wei Yang 2019-09-17 15:10 ` [Qemu-devel] [PULL 02/10] " Michael S. Tsirkin 2019-08-21 12:16 ` [Qemu-devel] [PATCH v3] virtio pmem: user document Pankaj Gupta 2019-08-26 12:46 ` Cornelia Huck 2019-09-16 6:30 ` Pankaj Gupta 2019-09-17 15:11 ` [Qemu-devel] [PULL 09/10] " Michael S. Tsirkin 2019-08-22 18:34 ` [Qemu-devel] [PATCH 1/2] vhost-user-blk: prevent using uninitialized vqs Raphael Norwitz 2019-08-22 18:34 ` [Qemu-devel] [PATCH 2/2] backends/vhost-user.c: " Raphael Norwitz 2019-08-28 8:29 ` Stefan Hajnoczi 2019-09-17 15:10 ` [Qemu-devel] [PULL 04/10] " Michael S. Tsirkin 2019-08-23 3:43 ` [Qemu-devel] [Qemu-block] [PATCH 1/2] vhost-user-blk: " yuchenlin via Qemu-devel 2019-08-28 8:28 ` [Qemu-devel] " Stefan Hajnoczi 2019-09-17 15:10 ` [Qemu-devel] [PULL 03/10] " Michael S. Tsirkin 2019-09-10 14:03 ` [Qemu-devel] [PATCH v2] MAINTAINERS: update virtio-rng and virtio-serial maintainer Laurent Vivier 2019-09-17 15:10 ` [Qemu-devel] [PULL 01/10] " Michael S. Tsirkin 2019-09-13 12:06 ` [Qemu-devel] [PATCH v3] virtio-mmio: implement modern (v2) personality (virtio-1) Sergio Lopez 2019-09-16 14:40 ` Cornelia Huck 2019-09-17 15:11 ` [Qemu-devel] [PULL 10/10] " Michael S. Tsirkin 2019-09-21 7:06 ` [Qemu-devel] [PATCH v3] virtio-mmio: implement modern (v2), " Vasyl Vavrychuk 2019-09-23 13:58 ` Sergio Lopez 2019-09-19 10:13 ` [Qemu-devel] [PULL 00/10] virtio, vhost, pc: features, fixes, cleanups Peter Maydell
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190916080718.3299-2-peterx@redhat.com \ --to=peterx@redhat.com \ --cc=alex.williamson@redhat.com \ --cc=berrange@redhat.com \ --cc=bsd@redhat.com \ --cc=ehabkost@redhat.com \ --cc=eric.auger@redhat.com \ --cc=imammedo@redhat.com \ --cc=jasowang@redhat.com \ --cc=mst@redhat.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=rth@twiddle.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).