LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Maxim Levitsky <mlevitsk@redhat.com>,
	Erdem Aktas <erdemaktas@google.com>,
	linux-kselftest@vger.kernel.org
Cc: Sean Christopherson <seanjc@google.com>,
	Peter Gonda <pgonda@google.com>, Marc Orr <marcorr@google.com>,
	Sagi Shahar <sagis@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Shuah Khan <shuah@kernel.org>, Andrew Jones <drjones@redhat.com>,
	Ben Gardon <bgardon@google.com>, Peter Xu <peterx@redhat.com>,
	David Matlack <dmatlack@google.com>,
	Emanuele Giuseppe Esposito <eesposit@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Ricardo Koller <ricarkol@google.com>,
	Eric Auger <eric.auger@redhat.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Aaron Lewis <aaronlewis@google.com>,
	Jim Mattson <jmattson@google.com>,
	Oliver Upton <oupton@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Peter Shier <pshier@google.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Zhenzhong Duan <zhenzhong.duan@intel.com>,
	"Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>,
	Like Xu <like.xu@linux.intel.com>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>
Subject: Re: [RFC PATCH 1/4] KVM: selftests: Add support for creating non-default type VMs
Date: Wed, 4 Aug 2021 22:42:21 +0800	[thread overview]
Message-ID: <42a812a9-7f17-2a26-d289-1f921408a469@intel.com> (raw)
In-Reply-To: <ede70f11e713ee0140c0e684c3d46b3aa1176e5e.camel@redhat.com>

On 8/4/2021 10:24 PM, Maxim Levitsky wrote:
> On Wed, 2021-08-04 at 14:09 +0800, Xiaoyao Li wrote:
>> On 7/27/2021 2:37 AM, Erdem Aktas wrote:
>>> Currently vm_create function only creates KVM_X86_LEGACY_VM type VMs.
>>> Changing the vm_create function to accept type parameter to create
>>> new VM types.
>>>
>>> Signed-off-by: Erdem Aktas <erdemaktas@google.com>
>>> Reviewed-by: Sean Christopherson <seanjc@google.com>
>>> Reviewed-by: Peter Gonda <pgonda@google.com>
>>> Reviewed-by: Marc Orr <marcorr@google.com>
>>> Reviewed-by: Sagi Shahar <sagis@google.com>
>>> ---
>>>    .../testing/selftests/kvm/include/kvm_util.h  |  1 +
>>>    tools/testing/selftests/kvm/lib/kvm_util.c    | 29 +++++++++++++++++--
>>>    2 files changed, 27 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
>>> index d53bfadd2..c63df42d6 100644
>>> --- a/tools/testing/selftests/kvm/include/kvm_util.h
>>> +++ b/tools/testing/selftests/kvm/include/kvm_util.h
>>> @@ -88,6 +88,7 @@ int vcpu_enable_cap(struct kvm_vm *vm, uint32_t vcpu_id,
>>>    void vm_enable_dirty_ring(struct kvm_vm *vm, uint32_t ring_size);
>>>    
>>>    struct kvm_vm *vm_create(enum vm_guest_mode mode, uint64_t phy_pages, int perm);
>>> +struct kvm_vm *__vm_create(enum vm_guest_mode mode, uint64_t phy_pages, int perm, int type);
>>>    void kvm_vm_free(struct kvm_vm *vmp);
>>>    void kvm_vm_restart(struct kvm_vm *vmp, int perm);
>>>    void kvm_vm_release(struct kvm_vm *vmp);
>>> diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c
>>> index e5fbf16f7..70caa3882 100644
>>> --- a/tools/testing/selftests/kvm/lib/kvm_util.c
>>> +++ b/tools/testing/selftests/kvm/lib/kvm_util.c
>>> @@ -180,13 +180,36 @@ _Static_assert(sizeof(vm_guest_mode_params)/sizeof(struct vm_guest_mode_params)
>>>     * Return:
>>>     *   Pointer to opaque structure that describes the created VM.
>>>     *
>>> - * Creates a VM with the mode specified by mode (e.g. VM_MODE_P52V48_4K).
>>> + * Wrapper VM Create function to create a VM with default type (0).
>>
>> Can we pass KVM_X86_LEGACY_VM (whatever name when it's upstreamed)
>> instead of 0?
> 
> To be honest I would prefer this to be called something like KVM_X86_STANDARD_VM,
> or something.
> 
> I don't think that normal unencrypted virtualization is already legacy, even if TDX
> docs claim that.

I'm not proposing to use this specific name introduced in TDX RFC 
series, but proposing to use the name defined in KVM in the future 
instead of hard-coded 0.

Yes, KVM_X86_STANDARD_VM or KVM_X86_NORMAL_VM (proposed by Paolo) is 
better than KVM_X86_LEGACY_VM.

> Just my personal opinion.
> 
> Best regards,
> 	Maxim Levitsky
> 
>>
>>> + */
>>> +struct kvm_vm *vm_create(enum vm_guest_mode mode, uint64_t phy_pages, int perm)
>>> +{
>>> +	return __vm_create(mode, phy_pages, perm, 0);
>>> +}
>>> +
>>
>>
> 
> 


  reply	other threads:[~2021-08-04 14:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 18:37 [RFC PATCH 0/4] TDX KVM selftests Erdem Aktas
2021-07-26 18:37 ` [RFC PATCH 1/4] KVM: selftests: Add support for creating non-default type VMs Erdem Aktas
2021-07-26 22:26   ` David Matlack
2021-07-27 20:47     ` Sean Christopherson
2021-07-28 16:07       ` David Matlack
2021-07-28 20:11         ` Andrew Jones
2021-08-04  6:09   ` Xiaoyao Li
2021-08-04 14:24     ` Maxim Levitsky
2021-08-04 14:42       ` Xiaoyao Li [this message]
2021-08-04 14:45         ` Maxim Levitsky
2021-08-04 20:29           ` Erdem Aktas
2021-08-04 23:31             ` Sean Christopherson
2021-07-26 18:37 ` [RFC PATCH 2/4] KVM: selftest: Add helper functions to create TDX VMs Erdem Aktas
2021-07-26 18:37 ` [RFC PATCH 3/4] KVM: selftest: Adding TDX life cycle test Erdem Aktas
2021-07-26 22:42   ` David Matlack
2021-07-26 18:37 ` [RFC PATCH 4/4] KVM: selftest: Adding test case for TDX port IO Erdem Aktas
2021-07-28  4:02 ` [RFC PATCH 0/4] TDX KVM selftests Duan, Zhenzhong

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=42a812a9-7f17-2a26-d289-1f921408a469@intel.com \
    --to=xiaoyao.li@intel.com \
    --cc=aaronlewis@google.com \
    --cc=axelrasmussen@google.com \
    --cc=bgardon@google.com \
    --cc=borntraeger@de.ibm.com \
    --cc=dmatlack@google.com \
    --cc=drjones@redhat.com \
    --cc=eesposit@redhat.com \
    --cc=erdemaktas@google.com \
    --cc=eric.auger@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=like.xu@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maciej.szmigiero@oracle.com \
    --cc=marcorr@google.com \
    --cc=mlevitsk@redhat.com \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pgonda@google.com \
    --cc=pshier@google.com \
    --cc=ricarkol@google.com \
    --cc=sagis@google.com \
    --cc=seanjc@google.com \
    --cc=shuah@kernel.org \
    --cc=vkuznets@redhat.com \
    --cc=wangyanan55@huawei.com \
    --cc=zhenzhong.duan@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).