* Daniel P. Berrang? <berra...@redhat.com> [2024-05-16 16:04:24]: > On Thu, May 16, 2024 at 02:33:47PM +0000, Srivatsa Vaddagiri wrote: > > This adds support to launch hypervisor-assisted confidential guests, > > where guest's memory is protected from a potentially untrusted host. > > Hypervisor can setup host's page-tables so that it loses access to guest > > memory. > > > > Since some guest drivers may need to communicate data with their host > > counterparts via shared memory, optionally allow setting aside some part > > of the confidential guest's memory as "shared". The size of this shared > > memory is specified via the optional "swiotlb-size" parameter. > > > > -machine virt,confidential-guest-support=prot0 \ > > -object arm-confidential-guest,id=prot0,swiotlb-size=16777216 > > > > The size of this shared memory is indicated to the guest in size/reg > > property of device-tree node "/reserved-memory/restricted_dma_reserved". > > A memory-region property is added to device-tree node representing > > virtio-pcie hub, so that all DMA allocations requested by guest's > > virtio-pcie > > device drivers are satisfied from the shared swiotlb region. > > For reference, there is another series proposing confidential guest > support for the 'virt' machine on AArch64 with KVM > > https://lists.nongnu.org/archive/html/qemu-devel/2024-04/msg02742.html > > I've no idea how closely your impl matches the KVM proposed impl. ie > whether we need 2 distinct "ConfidentialGuest" subclasses for KVM vs > Gunyah, or whether 1 can cope with both. If we do need 2 distinct > subclasses for each hypervisor, then calling this Gunyah targetted > object 'arm-confidential-guest' is too broad of an name.
Thanks for that pointer! Let me study the proposed KVM implementation and see how we can consolidate support for KVM and Gunyah hypervisors. - vatsa
