>-----Original Message-----
>From: Ashish Kalra <Ashish.Kalra@xxxxxxx>
>Sent: Thursday, September 02, 2021 22:05
>To: yuan.yao@xxxxxxxxxxxxxxx
>Cc: Thomas.Lendacky@xxxxxxx; armbru@xxxxxxxxxx; ashish.kalra@xxxxxxx; brijesh.singh@xxxxxxx;
>dgilbert@xxxxxxxxxx; ehabkost@xxxxxxxxxx; Yamahata, Isaku <isaku.yamahata@xxxxxxxxx>; kvm@xxxxxxxxxxxxxxx;
>mst@xxxxxxxxxx; mtosatti@xxxxxxxxxx; pbonzini@xxxxxxxxxx; qemu-devel@xxxxxxxxxx; Yao, Yuan
><yuan.yao@xxxxxxxxx>
>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
