Received-SPF: pass (google.com: domain of linux-kernel+bounces-189922-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <6a7b865f-9513-4dd2-9aff-e8f19dea6d90@linux.intel.com>
Date: Mon, 27 May 2024 08:57:28 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v19 105/130] KVM: TDX: handle KVM hypercall with
 TDG.VP.VMCALL
To: Isaku Yamahata <isaku.yamahata@intel.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Sean Christopherson <seanjc@google.com>
Cc: Chao Gao <chao.gao@intel.com>, kvm@vger.kernel.org,
 linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com,
 erdemaktas@google.com, Sagi Shahar <sagis@google.com>,
 Kai Huang <kai.huang@intel.com>, chen.bo@intel.com, hang.yuan@intel.com,
 tina.zhang@intel.com, isaku.yamahata@linux.intel.com
References: <cover.1708933498.git.isaku.yamahata@intel.com>
 <ab54980da397e6e9b7b8d6636dc88c11c303364f.1708933498.git.isaku.yamahata@intel.com>
 <ZgvHXk/jiWzTrcWM@chao-email>
 <20240404012726.GP2444378@ls.amr.corp.intel.com>
 <8d489a08-784b-410d-8714-3c0ffc8dfb39@linux.intel.com>
 <20240417070240.GF3039520@ls.amr.corp.intel.com>
Content-Language: en-US
From: Binbin Wu <binbin.wu@linux.intel.com>
In-Reply-To: <20240417070240.GF3039520@ls.amr.corp.intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 4/17/2024 3:02 PM, Isaku Yamahata wrote:
> On Wed, Apr 17, 2024 at 02:16:57PM +0800,
> Binbin Wu <binbin.wu@linux.intel.com> wrote:
>
>>
>> On 4/4/2024 9:27 AM, Isaku Yamahata wrote:
>>> On Tue, Apr 02, 2024 at 04:52:46PM +0800,
>>> Chao Gao <chao.gao@intel.com> wrote:
>>>
>>>>> +static int tdx_emulate_vmcall(struct kvm_vcpu *vcpu)
>>>>> +{
>>>>> +	unsigned long nr, a0, a1, a2, a3, ret;
>>>>> +
>>>> do you need to emulate xen/hyper-v hypercalls here?
>>> No. kvm_emulate_hypercall() handles xen/hyper-v hypercalls,
>>> __kvm_emulate_hypercall() doesn't.
>> So for TDX, kvm doesn't support xen/hyper-v, right?
>>
>> Then, should KVM_CAP_XEN_HVM and KVM_CAP_HYPERV be filtered out for TDX?
> That's right. We should update kvm_vm_ioctl_check_extension() and
> kvm_vcpu_ioctl_enable_cap().  I didn't pay attention to them.
Currently, QEMU checks the capabilities for Hyper-v/Xen via 
kvm_check_extension(), which is the global version.
Only modifications in KVM can't hide these capabilities. It needs 
userspace to use VM or vCPU version to check the capabilities for 
Hyper-v and Xen.
Is it a change of ABI when the old global version is still workable, but 
userspace switches to use VM/vCPU version to check capabilities for 
Hyper-v and Xen?
Are there objections if both QEMU and KVM are modified in order to 
hide Hyper-v/Xen capabilities for TDX?