All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Binbin Wu <binbin.wu@linux.intel.com>
Cc: pbonzini@redhat.com, seanjc@google.com, kvm@vger.kernel.org,
	rick.p.edgecombe@intel.com, kai.huang@intel.com,
	adrian.hunter@intel.com, reinette.chatre@intel.com,
	tony.lindgren@linux.intel.com, isaku.yamahata@intel.com,
	yan.y.zhao@intel.com, chao.gao@intel.com, michael.roth@amd.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/7] KVM: TDX: Handle TDG.VP.VMCALL<MapGPA>
Date: Mon, 16 Dec 2024 14:03:23 +0800	[thread overview]
Message-ID: <edc7f1f3-e498-44cc-aa3c-994d3f290e01@intel.com> (raw)
In-Reply-To: <692aacc1-809f-449d-8f67-8e8e7ede8c8d@linux.intel.com>

On 12/16/2024 9:08 AM, Binbin Wu wrote:
> 
> 
> 
> On 12/13/2024 5:32 PM, Xiaoyao Li wrote:
>> On 12/1/2024 11:53 AM, Binbin Wu wrote:
>>
> [...]
>>> +
>>> +static int tdx_map_gpa(struct kvm_vcpu *vcpu)
>>> +{
>>> +    struct vcpu_tdx * tdx = to_tdx(vcpu);
>>> +    u64 gpa = tdvmcall_a0_read(vcpu);
>>
>> We can use kvm_r12_read() directly, which is more intuitive. And we 
>> can drop the MACRO for a0/a1/a2/a3 accessors in patch 022.
> I am neutral about it.
> 

a0, a1, a2, a3, are the name convention for KVM's hypercall. It makes 
sense when serving as the parameters to  __kvm_emulate_hypercall().

However, now __kvm_emulate_hypercall() is made to a MACRO and we don't 
need the temp variable like a0 = kvm_xx_read().

For TDVMCALL leafs other than normal KVM hypercalls, they are all TDX 
specific and defined in TDX GHCI spec, a0/a1/a2/a3 makes no sense for them.

> 
>>
>>> +    u64 size = tdvmcall_a1_read(vcpu);
>>> +    u64 ret;
>>> +
>>> +    /*
>>> +     * Converting TDVMCALL_MAP_GPA to KVM_HC_MAP_GPA_RANGE requires
>>> +     * userspace to enable KVM_CAP_EXIT_HYPERCALL with 
>>> KVM_HC_MAP_GPA_RANGE
>>> +     * bit set.  If not, the error code is not defined in GHCI for 
>>> TDX, use
>>> +     * TDVMCALL_STATUS_INVALID_OPERAND for this case.
>>> +     */
>>> +    if (!user_exit_on_hypercall(vcpu->kvm, KVM_HC_MAP_GPA_RANGE)) {
>>> +        ret = TDVMCALL_STATUS_INVALID_OPERAND;
>>> +        goto error;
>>> +    }
>>> +
>>> +    if (gpa + size <= gpa || !kvm_vcpu_is_legal_gpa(vcpu, gpa) ||
>>> +        !kvm_vcpu_is_legal_gpa(vcpu, gpa + size -1) ||
>>> +        (vt_is_tdx_private_gpa(vcpu->kvm, gpa) !=
>>> +         vt_is_tdx_private_gpa(vcpu->kvm, gpa + size -1))) {
>>> +        ret = TDVMCALL_STATUS_INVALID_OPERAND;
>>> +        goto error;
>>> +    }
>>> +
>>> +    if (!PAGE_ALIGNED(gpa) || !PAGE_ALIGNED(size)) {
>>> +        ret = TDVMCALL_STATUS_ALIGN_ERROR;
>>> +        goto error;
>>> +    }
>>> +
>>> +    tdx->map_gpa_end = gpa + size;
>>> +    tdx->map_gpa_next = gpa;
>>> +
>>> +    __tdx_map_gpa(tdx);
>>> +    /* Forward request to userspace. */
>>> +    return 0;
>>
>> Maybe let __tdx_map_gpa() return a int to decide whether it needs to 
>> return to userspace and
>>
>>     return __tdx_map_gpa(tdx);
>>
>> ?
> 
> To save one line of code and the comment?

No. Just I found most of the cases that need to exit to usespace, comes 
with "return 0" after setting up the run->exit_reason and run->(fields).

> Because MapGPA always goes to userspace, I don't want to make a function 
> return
> a int that is a fixed value.
> And if the multiple comments bother you, I think the comments can be 
> removed.
> 
>>
>>
>>> +
>>> +error:
>>> +    tdvmcall_set_return_code(vcpu, ret);
>>> +    kvm_r11_write(vcpu, gpa);
>>> +    return 1;
>>> +}
>>> +
>>>   static int handle_tdvmcall(struct kvm_vcpu *vcpu)
>>>   {
>>>       if (tdvmcall_exit_type(vcpu))
>>>           return tdx_emulate_vmcall(vcpu);
>>>         switch (tdvmcall_leaf(vcpu)) {
>>> +    case TDVMCALL_MAP_GPA:
>>> +        return tdx_map_gpa(vcpu);
>>>       default:
>>>           break;
>>>       }
>>> diff --git a/arch/x86/kvm/vmx/tdx.h b/arch/x86/kvm/vmx/tdx.h
>>> index 1abc94b046a0..bfae70887695 100644
>>> --- a/arch/x86/kvm/vmx/tdx.h
>>> +++ b/arch/x86/kvm/vmx/tdx.h
>>> @@ -71,6 +71,9 @@ struct vcpu_tdx {
>>>         enum tdx_prepare_switch_state prep_switch_state;
>>>       u64 msr_host_kernel_gs_base;
>>> +
>>> +    u64 map_gpa_next;
>>> +    u64 map_gpa_end;
>>>   };
>>>     void tdh_vp_rd_failed(struct vcpu_tdx *tdx, char *uclass, u32 
>>> field, u64 err);
>>
> 


  reply	other threads:[~2024-12-16  6:03 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-01  3:53 [PATCH 0/7] KVM: TDX: TDX hypercalls may exit to userspace Binbin Wu
2024-12-01  3:53 ` [PATCH 1/7] KVM: TDX: Add a place holder to handle TDX VM exit Binbin Wu
2024-12-09 11:21   ` Chao Gao
2024-12-10  2:14     ` Binbin Wu
2024-12-13  8:57   ` Xiaoyao Li
2024-12-16  0:54     ` Binbin Wu
2024-12-16  4:37       ` Xiaoyao Li
2024-12-18  1:33         ` Binbin Wu
2025-01-22 12:50   ` Paolo Bonzini
2024-12-01  3:53 ` [PATCH 2/7] KVM: TDX: Add a place holder for handler of TDX hypercalls (TDG.VP.VMCALL) Binbin Wu
2024-12-09 11:28   ` Chao Gao
2024-12-10  2:34     ` Binbin Wu
2024-12-01  3:53 ` [PATCH 3/7] KVM: TDX: Handle KVM hypercall with TDG.VP.VMCALL Binbin Wu
2024-12-09  2:58   ` Chao Gao
2024-12-09  3:08     ` Binbin Wu
2024-12-01  3:53 ` [PATCH 4/7] KVM: TDX: Handle TDG.VP.VMCALL<MapGPA> Binbin Wu
2024-12-09 12:45   ` Chao Gao
2024-12-10  2:51     ` Binbin Wu
2024-12-10  9:10       ` Chao Gao
2024-12-10  9:27         ` Tony Lindgren
2024-12-13  9:32   ` Xiaoyao Li
2024-12-16  1:08     ` Binbin Wu
2024-12-16  6:03       ` Xiaoyao Li [this message]
2024-12-18  1:38         ` Binbin Wu
2024-12-18  5:09           ` Binbin Wu
2024-12-01  3:53 ` [PATCH 5/7] KVM: TDX: Handle TDG.VP.VMCALL<ReportFatalError> Binbin Wu
2024-12-06  9:31   ` Xu Yilun
2024-12-06  9:37     ` Binbin Wu
2024-12-10  9:05   ` Chao Gao
2024-12-10  9:43     ` Binbin Wu
2024-12-13  9:40   ` Xiaoyao Li
2024-12-16  1:14     ` Binbin Wu
2024-12-01  3:53 ` [PATCH 6/7] KVM: TDX: Handle TDX PV port I/O hypercall Binbin Wu
2024-12-10  9:42   ` Chao Gao
2024-12-10  9:50     ` Binbin Wu
2024-12-01  3:53 ` [PATCH 7/7] KVM: TDX: Handle TDX PV MMIO hypercall Binbin Wu
2024-12-10 18:24 ` [PATCH 0/7] KVM: TDX: TDX hypercalls may exit to userspace Paolo Bonzini

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=edc7f1f3-e498-44cc-aa3c-994d3f290e01@intel.com \
    --to=xiaoyao.li@intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=chao.gao@intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=tony.lindgren@linux.intel.com \
    --cc=yan.y.zhao@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 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.