>-----Original Message-----
>From: Ashish Kalra <ashish.ka...@amd.com>
>Sent: Thursday, September 02, 2021 22:05
>To: yuan....@linux.intel.com
>Cc: thomas.lenda...@amd.com; arm...@redhat.com; ashish.ka...@amd.com;
>brijesh.si...@amd.com;
>dgilb...@redhat.com; ehabk...@redhat.com; Yamahata, Isaku
><isaku.yamah...@intel.com>; k...@vger.kernel.org;
>m...@redhat.com; mtosa...@redhat.com; pbonz...@redhat.com;
>qemu-devel@nongnu.org; Yao, Yuan
><yuan....@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
