From: "Yao, Yuan" <yuan.yao@intel.com> To: Ashish Kalra <Ashish.Kalra@amd.com>, "yuan.yao@linux.intel.com" <yuan.yao@linux.intel.com> Cc: "Thomas.Lendacky@amd.com" <Thomas.Lendacky@amd.com>, "armbru@redhat.com" <armbru@redhat.com>, "brijesh.singh@amd.com" <brijesh.singh@amd.com>, "dgilbert@redhat.com" <dgilbert@redhat.com>, "ehabkost@redhat.com" <ehabkost@redhat.com>, "Yamahata, Isaku" <isaku.yamahata@intel.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "mst@redhat.com" <mst@redhat.com>, "mtosatti@redhat.com" <mtosatti@redhat.com>, "pbonzini@redhat.com" <pbonzini@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org> Subject: RE: [RFC][PATCH v1 00/10] Enable encrypted guest memory access in QEMU Date: Thu, 2 Sep 2021 23:23:50 +0000 [thread overview] Message-ID: <BYAPR11MB37179FAB0D067E0177498E2795CE9@BYAPR11MB3717.namprd11.prod.outlook.com> (raw) In-Reply-To: <20210902140433.12994-1-Ashish.Kalra@amd.com> >-----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
WARNING: multiple messages have this Message-ID (diff)
From: "Yao, Yuan" <yuan.yao@intel.com> To: Ashish Kalra <Ashish.Kalra@amd.com>, "yuan.yao@linux.intel.com" <yuan.yao@linux.intel.com> Cc: "Yamahata, Isaku" <isaku.yamahata@intel.com>, "Thomas.Lendacky@amd.com" <Thomas.Lendacky@amd.com>, "brijesh.singh@amd.com" <brijesh.singh@amd.com>, "ehabkost@redhat.com" <ehabkost@redhat.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "mst@redhat.com" <mst@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "mtosatti@redhat.com" <mtosatti@redhat.com>, "armbru@redhat.com" <armbru@redhat.com>, "dgilbert@redhat.com" <dgilbert@redhat.com>, "pbonzini@redhat.com" <pbonzini@redhat.com> Subject: RE: [RFC][PATCH v1 00/10] Enable encrypted guest memory access in QEMU Date: Thu, 2 Sep 2021 23:23:50 +0000 [thread overview] Message-ID: <BYAPR11MB37179FAB0D067E0177498E2795CE9@BYAPR11MB3717.namprd11.prod.outlook.com> (raw) In-Reply-To: <20210902140433.12994-1-Ashish.Kalra@amd.com> >-----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
next prev parent reply other threads:[~2021-09-02 23:24 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-06 1:40 [RFC][PATCH v1 00/10] Enable encrypted guest memory access in QEMU Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 01/10] Extend the MemTxAttrs to include a 'debug' flag. The flag can be used as general indicator that operation was triggered by the debugger Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 02/10] Currently, guest memory access for debugging purposes is performed using memcpy(). Extend the 'struct MemoryRegion' to include new callbacks that can be used to override the use of memcpy() with something else Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 03/10] Introduce new interface KVMState::set_mr_debug_ops and its wrapper Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 04/10] Implements the common MemoryRegion::ram_debug_ops for encrypted guests Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 05/10] Set the RAM's MemoryRegion::debug_ops for INTEL TD guests Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 06/10] Introduce new MemoryDebugOps which hook into guest virtual and physical memory debug interfaces such as cpu_memory_rw_debug, to allow vendor specific assist/hooks for debugging and delegating accessing the guest memory. This is required for example in case of AMD SEV platform where the guest memory is encrypted and a SEV specific debug assist/hook will be required to access the guest memory Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 07/10] Add new address_space_read and address_space_write debug helper interfaces which can be invoked by vendor specific guest memory debug assist/hooks to do guest RAM memory accesses using the added MemoryRegion callbacks Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 08/10] Introduce debug version of physical memory read/write API Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 09/10] Change the monitor and other commands and gdbstub to use the debug API Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-05-06 1:40 ` [RFC][PATCH v1 10/10] Introduce new CPUClass::get_phys_page_attrs_debug implementation for encrypted guests Yuan Yao 2021-05-06 1:40 ` Yuan Yao 2021-09-02 14:04 ` [RFC][PATCH v1 00/10] Enable encrypted guest memory access in QEMU Ashish Kalra 2021-09-02 23:23 ` Yao, Yuan [this message] 2021-09-02 23:23 ` Yao, Yuan 2021-09-07 10:51 ` Ashish Kalra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=BYAPR11MB37179FAB0D067E0177498E2795CE9@BYAPR11MB3717.namprd11.prod.outlook.com \ --to=yuan.yao@intel.com \ --cc=Ashish.Kalra@amd.com \ --cc=Thomas.Lendacky@amd.com \ --cc=armbru@redhat.com \ --cc=brijesh.singh@amd.com \ --cc=dgilbert@redhat.com \ --cc=ehabkost@redhat.com \ --cc=isaku.yamahata@intel.com \ --cc=kvm@vger.kernel.org \ --cc=mst@redhat.com \ --cc=mtosatti@redhat.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=yuan.yao@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.