search for: pseries_secure_vm

...e, but not generally so if > > we were to go down the route of a quirk in virtio, it might be better to > > make it painfully obvious that it's specific to that one case with a different > > kind of turd: > > > > - if (xen_domain()) > > + if (xen_domain() || pseries_secure_vm()) > > return true; > > I don't think it's pseries specific actually. E.g. I suspect AMD SEV > might benefit from the same kind of hack. As long as they can provide the same guarantee that the DMA ops are completely equivalent between virtio and other PCI devices, at leas...

...valent. We can provide that guarantee for our secure VM case, but not generally so if we were to go down the route of a quirk in virtio, it might be better to make it painfully obvious that it's specific to that one case with a different kind of turd: - if (xen_domain()) + if (xen_domain() || pseries_secure_vm()) return true; So to summarize, and make sure I'm not missing something, the two approaches at hand are either: 1- The above, which is a one liner and contained in the guest, so that's nice, but also means another turd in virtio which isn't ... 2- We force pseries to always set...

...valent. We can provide that guarantee for our secure VM case, but not generally so if we were to go down the route of a quirk in virtio, it might be better to make it painfully obvious that it's specific to that one case with a different kind of turd: - if (xen_domain()) + if (xen_domain() || pseries_secure_vm()) return true; So to summarize, and make sure I'm not missing something, the two approaches at hand are either: 1- The above, which is a one liner and contained in the guest, so that's nice, but also means another turd in virtio which isn't ... 2- We force pseries to always set...

...uarantee for our secure VM case, but not generally so if > we were to go down the route of a quirk in virtio, it might be better to > make it painfully obvious that it's specific to that one case with a different > kind of turd: > > - if (xen_domain()) > + if (xen_domain() || pseries_secure_vm()) > return true; I don't think it's pseries specific actually. E.g. I suspect AMD SEV might benefit from the same kind of hack. > So to summarize, and make sure I'm not missing something, the two approaches > at hand are either: > > 1- The above, which is a one li...

On Tue, 2018-08-07 at 23:31 -0700, Christoph Hellwig wrote: > > You don't need to set them the time you go secure. You just need to > set the flag from the beginning on any VM you might want to go secure. > Or for simplicity just any VM - if the DT/ACPI tables exposed by > qemu are good enough that will always exclude a iommu and not set a > DMA offset, so nothing will

On Tue, 2018-08-07 at 23:31 -0700, Christoph Hellwig wrote: > > You don't need to set them the time you go secure. You just need to > set the flag from the beginning on any VM you might want to go secure. > Or for simplicity just any VM - if the DT/ACPI tables exposed by > qemu are good enough that will always exclude a iommu and not set a > DMA offset, so nothing will