From: David Hildenbrand <david@redhat.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>, Markus Armbruster <armbru@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Peter Xu" <peterx@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Cornelia Huck" <cohuck@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
"Michael Roth" <michael.roth@amd.com>,
isaku.yamahata@gmail.com,
"Sean Christopherson" <seanjc@google.com>,
"Claudio Fontana" <cfontana@suse.de>
Subject: Re: [RFC PATCH v2 03/21] HostMem: Add private property and associate it with RAM_KVM_GMEM
Date: Wed, 20 Sep 2023 16:37:37 +0200 [thread overview]
Message-ID: <091a40cb-ec26-dd79-aa26-191dc59c03e6@redhat.com> (raw)
In-Reply-To: <da598ffc-fa47-3c25-64ea-27ea90d712aa@intel.com>
On 20.09.23 16:35, Xiaoyao Li wrote:
> On 9/20/2023 3:30 PM, Markus Armbruster wrote:
>> Xiaoyao Li <xiaoyao.li@intel.com> writes:
>>
>>> On 9/19/2023 5:46 PM, Markus Armbruster wrote:
>>>> Xiaoyao Li <xiaoyao.li@intel.com> writes:
>>>>
>>>>> From: Isaku Yamahata <isaku.yamahata@intel.com>
>>>>>
>>>>> Add a new property "private" to memory backends. When it's set to true,
>>>>> it indicates the RAMblock of the backend also requires kvm gmem.
>>>> Can you add a brief explanation why you need the property?
>>>
>>> It provides a mechanism for user to specify whether the memory can serve as private memory (need request kvm gmem).
>>
>> Yes, but why would a user want such memory?
>>
>
> Because KVM demands it for confidential guest, e.g., TDX guest. KVM
> demands that the mem slot needs to have KVM_MEM_PRIVATE set and has
> valid gmem associated if the guest accesses it as private memory.
I think as long as there is no demand to have a TDX guest with this
property be set to "off", then just don't add it.
With a TDX VM, it will can be implicitly active. If we ever have to
disable it for selective memory backends, we can add the property and
have something like on/off/auto. For now it would be "auto".
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2023-09-20 14:38 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 3:50 [RFC PATCH v2 00/21] QEMU gmem implemention Xiaoyao Li
2023-09-14 3:50 ` [RFC PATCH v2 01/21] *** HACK *** linux-headers: Update headers to pull in gmem APIs Xiaoyao Li
2023-09-14 3:50 ` [RFC PATCH v2 02/21] RAMBlock: Add support of KVM private gmem Xiaoyao Li
2023-09-15 2:04 ` Wang, Lei
2023-09-15 3:45 ` Xiaoyao Li
2023-09-21 8:55 ` David Hildenbrand
2023-09-22 0:22 ` Xiaoyao Li
2023-09-22 7:08 ` David Hildenbrand
2023-10-08 2:59 ` Xiaoyao Li
2023-10-06 11:07 ` Daniel P. Berrangé
2023-09-14 3:50 ` [RFC PATCH v2 03/21] HostMem: Add private property and associate it with RAM_KVM_GMEM Xiaoyao Li
2023-09-19 9:46 ` Markus Armbruster
2023-09-19 23:24 ` Xiaoyao Li
2023-09-20 7:30 ` Markus Armbruster
2023-09-20 14:35 ` Xiaoyao Li
2023-09-20 14:37 ` David Hildenbrand [this message]
2023-09-20 15:42 ` Markus Armbruster
2023-09-21 8:38 ` Xiaoyao Li
2023-09-21 8:45 ` David Hildenbrand
2023-09-14 3:51 ` [RFC PATCH v2 04/21] memory: Introduce memory_region_has_gmem_fd() Xiaoyao Li
2023-09-21 8:46 ` David Hildenbrand
2023-09-22 0:22 ` Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 05/21] kvm: Enable KVM_SET_USER_MEMORY_REGION2 for memslot Xiaoyao Li
2023-09-21 8:56 ` David Hildenbrand
2023-09-22 0:23 ` Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 06/21] i386: Add support for sw-protected-vm object Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 07/21] i386/pc: Drop pc_machine_kvm_type() Xiaoyao Li
2023-09-21 8:51 ` David Hildenbrand
2023-09-22 0:24 ` Xiaoyao Li
2023-09-22 7:11 ` David Hildenbrand
2023-09-23 7:32 ` David Woodhouse
2023-09-14 3:51 ` [RFC PATCH v2 08/21] target/i386: Implement mc->kvm_type() to get VM type Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 09/21] target/i386: Introduce kvm_confidential_guest_init() Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 10/21] i386/kvm: Implement kvm_sw_protected_vm_init() for sw-protcted-vm specific functions Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 11/21] kvm: Introduce support for memory_attributes Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 12/21] kvm/memory: Introduce the infrastructure to set the default shared/private value Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 13/21] i386/kvm: Set memory to default private for KVM_X86_SW_PROTECTED_VM Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 14/21] physmem: replace function name with __func__ in ram_block_discard_range() Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 15/21] physmem: extract ram_block_discard_range_fd() from ram_block_discard_range() Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 16/21] physmem: Introduce ram_block_convert_range() Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 17/21] kvm: handle KVM_EXIT_MEMORY_FAULT Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 18/21] trace/kvm: Add trace for page convertion between shared and private Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 19/21] pci-host/q35: Move PAM initialization above SMRAM initialization Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 20/21] q35: Introduce smm_ranges property for q35-pci-host Xiaoyao Li
2023-09-14 3:51 ` [RFC PATCH v2 21/21] i386: Disable SMM mode for X86_SW_PROTECTED_VM Xiaoyao Li
2023-09-14 13:09 ` [RFC PATCH v2 00/21] QEMU gmem implemention David Hildenbrand
2023-09-15 1:10 ` Sean Christopherson
2023-09-21 9:11 ` David Hildenbrand
2023-09-22 7:03 ` Xiaoyao Li
2023-09-22 7:10 ` David Hildenbrand
2023-09-15 3:37 ` Xiaoyao Li
2023-09-21 8:59 ` David Hildenbrand
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=091a40cb-ec26-dd79-aa26-191dc59c03e6@redhat.com \
--to=david@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=cfontana@suse.de \
--cc=cohuck@redhat.com \
--cc=eblake@redhat.com \
--cc=imammedo@redhat.com \
--cc=isaku.yamahata@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=seanjc@google.com \
--cc=xiaoyao.li@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).