>-----Original Message----- >From: Ashish Kalra <Ashish.Kalra@amd.com> >Sent: Thursday, September 02, 2021 22:05 >To: yuan.yao@linux.intel.com >Cc: Thomas.Lendacky@amd.com; armbru@redhat.com; ashish.kalra@amd.com; brijesh.singh@amd.com; >dgilbert@redhat.com; ehabkost@redhat.com; Yamahata, Isaku <isaku.yamahata@intel.com>; kvm@vger.kernel.org; >mst@redhat.com; mtosatti@redhat.com; pbonzini@redhat.com; qemu-devel@nongnu.org; Yao, Yuan ><yuan.yao@intel.com> >Subject: [RFC][PATCH v1 00/10] Enable encrypted guest memory access in QEMU > >> - We introduce another new vm level ioctl focus on the encrypted >> guest memory accessing: >> >> KVM_MEMORY_ENCRYPT_{READ,WRITE}_MEMORY >> >> struct kvm_rw_memory rw; >> rw.addr = gpa_OR_hva; >> rw.buf = (__u64)src; >> rw.len = len; >> kvm_vm_ioctl(kvm_state, >> KVM_MEMORY_ENCRYPT_{READ,WRITE}_MEMORY, >> &rw); >> >> This new ioctl has more neutral and general name for its >> purpose, the debugging support of AMD SEV and INTEL TDX >> can be covered by a unify QEMU implementation on x86 with this >> ioctl. Although only INTEL TD guest is supported in this series, >> AMD SEV could be also supported with implementation of this >> ioctl in KVM, plus small modifications in QEMU to enable the >> unify part. > >A general comment, we have sev_ioctl() interface for SEV guests and >probably this new vm level ioctl will not work for us. > >It probably makes more sense to do this TDX/SEV level abstraction >using the Memory Region's ram_debug_ops, which can point these to >TDX specific vm level ioctl and SEV specific ioctl at the lowest >level of this interface. > Hi Ashish, Yes, this new ioctl is now working as the low-level interface for Memory Region's ram_debug_ops. SEV can use kvm_setup_set_memory_region_debug_ops() to install a new callback to KVM for installing SEV only low-level implementation, then call kvm_set_memory_region_debug_ops() to do Memory Region's ram_debug_ops installation later. >Thanks, >Ashish
Hello Yuan, On Thu, Sep 02, 2021 at 11:23:50PM +0000, Yao, Yuan wrote: > >-----Original Message----- > >From: Ashish Kalra <Ashish.Kalra@amd.com> > >Sent: Thursday, September 02, 2021 22:05 > >To: yuan.yao@linux.intel.com > >Cc: Thomas.Lendacky@amd.com; armbru@redhat.com; ashish.kalra@amd.com; brijesh.singh@amd.com; > >dgilbert@redhat.com; ehabkost@redhat.com; Yamahata, Isaku <isaku.yamahata@intel.com>; kvm@vger.kernel.org; > >mst@redhat.com; mtosatti@redhat.com; pbonzini@redhat.com; qemu-devel@nongnu.org; Yao, Yuan > ><yuan.yao@intel.com> > >Subject: [RFC][PATCH v1 00/10] Enable encrypted guest memory access in QEMU > > > >> - We introduce another new vm level ioctl focus on the encrypted > >> guest memory accessing: > >> > >> KVM_MEMORY_ENCRYPT_{READ,WRITE}_MEMORY > >> > >> struct kvm_rw_memory rw; > >> rw.addr = gpa_OR_hva; > >> rw.buf = (__u64)src; > >> rw.len = len; > >> kvm_vm_ioctl(kvm_state, > >> KVM_MEMORY_ENCRYPT_{READ,WRITE}_MEMORY, > >> &rw); > >> > >> This new ioctl has more neutral and general name for its > >> purpose, the debugging support of AMD SEV and INTEL TDX > >> can be covered by a unify QEMU implementation on x86 with this > >> ioctl. Although only INTEL TD guest is supported in this series, > >> AMD SEV could be also supported with implementation of this > >> ioctl in KVM, plus small modifications in QEMU to enable the > >> unify part. > > > >A general comment, we have sev_ioctl() interface for SEV guests and > >probably this new vm level ioctl will not work for us. > > > >It probably makes more sense to do this TDX/SEV level abstraction > >using the Memory Region's ram_debug_ops, which can point these to > >TDX specific vm level ioctl and SEV specific ioctl at the lowest > >level of this interface. > > > Hi Ashish, > > Yes, this new ioctl is now working as the low-level interface for > Memory Region's ram_debug_ops. SEV can use > kvm_setup_set_memory_region_debug_ops() to install a new > callback to KVM for installing SEV only low-level implementation, > then call kvm_set_memory_region_debug_ops() to do Memory > Region's ram_debug_ops installation later. > > Ok. Yes i think that should work. Thanks, Ashish
© 2016 - 2024 Red Hat, Inc.