On Mon, 2018-06-04 at 18:57 +1000, David Gibson wrote: > > > - First qemu doesn't know that the guest will switch to "secure mode" > > in advance. There is no difference between a normal and a secure > > partition until the partition does the magic UV call to "enter secure > > mode" and qemu doesn't see any of it. So who can set the flag here ? > > This seems weird to me. As a rule HV calls should go through qemu - > or be allowed to go directly to KVM *by* qemu. It's not an HV call, it's a UV call, qemu won't see it, qemu isn't trusted. Now the UV *will* reflect that to the HV via some synthetized HV calls, and we *could* have those do a pass by qemu, however, so far, our entire design doesn't rely on *any* qemu knowledge whatsoever and it would be sad to add it just for that purpose. Additionally, this is rather orthogonal, see my other email, the problem we are trying to solve is *not* a qemu problem and it doesn't make sense to leak that into qemu. > We generally reserve > the latter for hot path things. Since this isn't a hot path, having > the call handled directly by the kernel seems wrong. > > Unless a "UV call" is something different I don't know about. Yes, a UV call goes to the Ultravisor, not the Hypervisor. The Hypervisor isn't trusted. > > - Second, when using VIRTIO_F_IOMMU_PLATFORM, we also make qemu (or > > vhost) go through the emulated MMIO for every access to the guest, > > which adds additional overhead. > Ben. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
