On Fri, 19 Jun 2020 13:16:38 +0100 Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: [..] > > > > > @@ -1165,6 +1167,15 @@ void machine_run_board_init(MachineState *machine) > > > > > * areas. > > > > > */ > > > > > machine_set_mem_merge(OBJECT(machine), false, &error_abort); > > > > > + > > > > > + /* > > > > > + * Virtio devices can't count on directly accessing guest > > > > > + * memory, so they need iommu_platform=on to use normal DMA > > > > > + * mechanisms. That requires disabling legacy virtio support > > > > > + * for virtio pci devices > > > > > + */ > > > > > + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on"); > > > > > + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on"); > > > > > } > > > > > > > > Silently changing the user's request configuration like this is a bad idea. > > > > The "disable-legacy" option in particular is undesirable as that switches > > > > the device to virtio-1.0 only mode, which exposes a different PCI ID to > > > > the guest. > > > > > > > > If some options are incompatible with encryption, then we should raise a > > > > fatal error at startup, so applications/admins are aware that their requested > > > > config is broken. > > > > > > Agreed - my suggestion is an on/off/auto property, auto value > > > changes automatically, on/off is validated. > > > > In fact should we extend all bit properties to allow an auto value? > > If "auto" was made the default that creates a similar headache, as to > preserve existing configuration semantics we expose to apps, libvirt > would need to find all the properties changed to use "auto" and manually > set them back to on/off explicitly. Hm, does that mean we can't change the default for any qemu property? I would expect that the defaults most remain invariant for any particular machine version. Conceptually, IMHO the default could change with a new machine version, but we would need some mechanism to ensure compatibility for old machine versions. Regards, Halil
