All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zeng Guang <guang.zeng@intel.com>
To: Yuan Yao <yuan.yao@linux.intel.com>
Cc: "Christopherson,, Sean" <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Kim Phillips <kim.phillips@amd.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Jethro Beekman <jethro@fortanix.com>,
	"Huang, Kai" <kai.huang@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Hu, Robert" <robert.hu@intel.com>,
	"Gao, Chao" <chao.gao@intel.com>
Subject: Re: [PATCH v5 5/8] KVM: x86: Support interrupt dispatch in x2APIC mode with APIC-write VM exit
Date: Tue, 18 Jan 2022 11:06:55 +0800	[thread overview]
Message-ID: <a46ce4d0-adfc-b149-e3aa-8b2f39e76e28@intel.com> (raw)
In-Reply-To: <20220118004405.po36x3lxi26mkwsz@yy-desk-7060>

On 1/18/2022 8:44 AM, Yuan Yao wrote:
> On Sat, Jan 15, 2022 at 10:08:10AM +0800, Zeng Guang wrote:
>> On 1/15/2022 1:34 AM, Sean Christopherson wrote:
>>> On Fri, Jan 14, 2022, Zeng Guang wrote:
>>>> kvm_lapic_reg_read() is limited to read up to 4 bytes. It needs extension to
>>>> support 64bit read.
>>> Ah, right.
>>>
>>>> And another concern is here getting reg value only specific from vICR(no
>>>> other regs need take care), going through whole path on kvm_lapic_reg_read()
>>>> could be time-consuming unnecessarily. Is it proper that calling
>>>> kvm_lapic_get_reg64() to retrieve vICR value directly?
>>> Hmm, no, I don't think that's proper.  Retrieving a 64-bit value really is unique
>>> to vICR.  Yes, the code does WARN on that, but if future architectural extensions
>>> even generate APIC-write exits on other registers, then using kvm_lapic_get_reg64()
>>> would be wrong and this code would need to be updated again.
>> Split on x2apic and WARN on (offset != APIC_ICR) already limit register read
>> to vICR only. Actually
>> we just need consider to deal with 64bit data specific to vICR in APIC-write
>> exits. From this point of
>> view, previous design can be compatible on handling other registers even if
>> future architectural
>> extensions changes. :)
>>> What about tweaking my prep patch from before to the below?  That would yield:
>>>
>>> 	if (apic_x2apic_mode(apic)) {
>>> 		if (WARN_ON_ONCE(offset != APIC_ICR))
>>> 			return 1;
>>>
>>> 		kvm_lapic_msr_read(apic, offset, &val);
>> I think it's problematic to use kvm_lapic_msr_read() in this case. It
>> premises the high 32bit value
>> already valid at APIC_ICR2, while in handling "nodecode" x2APIC writes we
>> need get continuous 64bit
>> data from offset 300H first and prepare emulation of APIC_ICR2 write. At
>> this time, APIC_ICR2 is not
>> ready yet.
> How about combine them, then you can handle the ICR write vmexit for
> IPI virtualization and Sean's patch can still work with code reusing,
> like below:
>
> 	if (apic_x2apic_mode(apic)) {
> 		if (WARN_ON_ONCE(offset != APIC_ICR))
> 			kvm_lapic_msr_read(apic, offset, &val);
> 		else
> 			kvm_lapic_get_reg64(apic, offset, &val);
>
> 		kvm_lapic_msr_write(apic, offset, val);
> 	} else {
> 		kvm_lapic_reg_read(apic, offset, 4, &val);
> 		kvm_lapic_reg_write(apic, offset, val);
> 	}

Alternatively we can merge as this if Sean think it ok to call 
kvm_lapic_get_reg64() retrieving 64bit data from vICR directly.

>>> 		kvm_lapic_msr_write(apic, offset, val);
>>> 	} else {
>>> 		kvm_lapic_reg_read(apic, offset, 4, &val);
>>> 		kvm_lapic_reg_write(apic, offset, val);
>>> 	}
>>>
>>> I like that the above has "msr" in the low level x2apic helpers, and it maximizes
>>> code reuse.  Compile tested only...
>>>
>>> From: Sean Christopherson <seanjc@google.com>
>>> Date: Fri, 14 Jan 2022 09:29:34 -0800
>>> Subject: [PATCH] KVM: x86: Add helpers to handle 64-bit APIC MSR read/writes
>>>
>>> Add helpers to handle 64-bit APIC read/writes via MSRs to deduplicate the
>>> x2APIC and Hyper-V code needed to service reads/writes to ICR.  Future
>>> support for IPI virtualization will add yet another path where KVM must
>>> handle 64-bit APIC MSR reads/write (to ICR).
>>>
>>> Opportunistically fix the comment in the write path; ICR2 holds the
>>> destination (if there's no shorthand), not the vector.
>>>
>>> No functional change intended.
>>>
>>> Signed-off-by: Sean Christopherson <seanjc@google.com>
>>> ---
>>>    arch/x86/kvm/lapic.c | 59 ++++++++++++++++++++++----------------------
>>>    1 file changed, 29 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>>> index f206fc35deff..cc4531eb448f 100644
>>> --- a/arch/x86/kvm/lapic.c
>>> +++ b/arch/x86/kvm/lapic.c
>>> @@ -2787,6 +2787,30 @@ int kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr)
>>>    	return 0;
>>>    }
>>>
>>> +static int kvm_lapic_msr_read(struct kvm_lapic *apic, u32 reg, u64 *data)
>>> +{
>>> +	u32 low, high = 0;
>>> +
>>> +	if (kvm_lapic_reg_read(apic, reg, 4, &low))
>>> +		return 1;
>>> +
>>> +	if (reg == APIC_ICR &&
>>> +	    WARN_ON_ONCE(kvm_lapic_reg_read(apic, APIC_ICR2, 4, &high)))
>>> +		return 1;
>>> +
>>> +	*data = (((u64)high) << 32) | low;
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int kvm_lapic_msr_write(struct kvm_lapic *apic, u32 reg, u64 data)
>>> +{
>>> +	/* For 64-bit ICR writes, set ICR2 (dest) before ICR (command). */
>>> +	if (reg == APIC_ICR)
>>> +		kvm_lapic_reg_write(apic, APIC_ICR2, (u32)(data >> 32));
>>> +	return kvm_lapic_reg_write(apic, reg, (u32)data);
>>> +}
>>> +
>>>    int kvm_x2apic_msr_write(struct kvm_vcpu *vcpu, u32 msr, u64 data)
>>>    {
>>>    	struct kvm_lapic *apic = vcpu->arch.apic;
>>> @@ -2798,16 +2822,13 @@ int kvm_x2apic_msr_write(struct kvm_vcpu *vcpu, u32 msr, u64 data)
>>>    	if (reg == APIC_ICR2)
>>>    		return 1;
>>>
>>> -	/* if this is ICR write vector before command */
>>> -	if (reg == APIC_ICR)
>>> -		kvm_lapic_reg_write(apic, APIC_ICR2, (u32)(data >> 32));
>>> -	return kvm_lapic_reg_write(apic, reg, (u32)data);
>>> +	return kvm_lapic_msr_write(apic, reg, data);
>>>    }
>>>
>>>    int kvm_x2apic_msr_read(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
>>>    {
>>>    	struct kvm_lapic *apic = vcpu->arch.apic;
>>> -	u32 reg = (msr - APIC_BASE_MSR) << 4, low, high = 0;
>>> +	u32 reg = (msr - APIC_BASE_MSR) << 4;
>>>
>>>    	if (!lapic_in_kernel(vcpu) || !apic_x2apic_mode(apic))
>>>    		return 1;
>>> @@ -2815,45 +2836,23 @@ int kvm_x2apic_msr_read(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
>>>    	if (reg == APIC_DFR || reg == APIC_ICR2)
>>>    		return 1;
>>>
>>> -	if (kvm_lapic_reg_read(apic, reg, 4, &low))
>>> -		return 1;
>>> -	if (reg == APIC_ICR)
>>> -		kvm_lapic_reg_read(apic, APIC_ICR2, 4, &high);
>>> -
>>> -	*data = (((u64)high) << 32) | low;
>>> -
>>> -	return 0;
>>> +	return kvm_lapic_msr_read(apic, reg, data);
>>>    }
>>>
>>>    int kvm_hv_vapic_msr_write(struct kvm_vcpu *vcpu, u32 reg, u64 data)
>>>    {
>>> -	struct kvm_lapic *apic = vcpu->arch.apic;
>>> -
>>>    	if (!lapic_in_kernel(vcpu))
>>>    		return 1;
>>>
>>> -	/* if this is ICR write vector before command */
>>> -	if (reg == APIC_ICR)
>>> -		kvm_lapic_reg_write(apic, APIC_ICR2, (u32)(data >> 32));
>>> -	return kvm_lapic_reg_write(apic, reg, (u32)data);
>>> +	return kvm_lapic_msr_write(vcpu->arch.apic, reg, data);
>>>    }
>>>
>>>    int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 reg, u64 *data)
>>>    {
>>> -	struct kvm_lapic *apic = vcpu->arch.apic;
>>> -	u32 low, high = 0;
>>> -
>>>    	if (!lapic_in_kernel(vcpu))
>>>    		return 1;
>>>
>>> -	if (kvm_lapic_reg_read(apic, reg, 4, &low))
>>> -		return 1;
>>> -	if (reg == APIC_ICR)
>>> -		kvm_lapic_reg_read(apic, APIC_ICR2, 4, &high);
>>> -
>>> -	*data = (((u64)high) << 32) | low;
>>> -
>>> -	return 0;
>>> +	return kvm_lapic_msr_read(vcpu->arch.apic, reg, data);
>>>    }
>>>
>>>    int kvm_lapic_set_pv_eoi(struct kvm_vcpu *vcpu, u64 data, unsigned long len)
>>> --

  reply	other threads:[~2022-01-18  3:27 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-31 14:28 [PATCH v5 0/8] IPI virtualization support for VM Zeng Guang
2021-12-31 14:28 ` [PATCH v5 1/8] x86/cpu: Add new VMX feature, Tertiary VM-Execution control Zeng Guang
2021-12-31 14:28 ` [PATCH v5 2/8] KVM: VMX: Extend BUILD_CONTROLS_SHADOW macro to support 64-bit variation Zeng Guang
2021-12-31 14:28 ` [PATCH v5 3/8] KVM: VMX: Detect Tertiary VM-Execution control when setup VMCS config Zeng Guang
2021-12-31 14:28 ` [PATCH v5 4/8] KVM: VMX: dump_vmcs() reports tertiary_exec_control field as well Zeng Guang
2022-01-13 21:03   ` Sean Christopherson
2022-01-14  4:19     ` Zeng Guang
2022-01-20  1:06       ` Sean Christopherson
2022-01-20  5:34         ` Zeng Guang
2021-12-31 14:28 ` [PATCH v5 5/8] KVM: x86: Support interrupt dispatch in x2APIC mode with APIC-write VM exit Zeng Guang
2022-01-13 21:29   ` Sean Christopherson
2022-01-14  7:52     ` Zeng Guang
2022-01-14 17:34       ` Sean Christopherson
2022-01-15  2:08         ` Zeng Guang
2022-01-18  0:44           ` Yuan Yao
2022-01-18  3:06             ` Zeng Guang [this message]
2022-01-18 18:17           ` Sean Christopherson
2022-01-19  2:48             ` Zeng Guang
2021-12-31 14:28 ` [PATCH v5 6/8] KVM: VMX: enable IPI virtualization Zeng Guang
2022-01-13 21:47   ` Sean Christopherson
2022-01-14  5:36     ` Zeng Guang
2021-12-31 14:28 ` [PATCH v5 7/8] KVM: VMX: Update PID-pointer table entry when APIC ID is changed Zeng Guang
2022-01-05 19:13   ` Tom Lendacky
2022-01-06  1:44     ` Zeng Guang
2022-01-06 14:06       ` Tom Lendacky
2022-01-07  8:05         ` Zeng Guang
2022-01-07  8:31           ` Maxim Levitsky
2022-01-10  7:45             ` Chao Gao
2022-01-10 22:24               ` Maxim Levitsky
2022-01-13 22:19                 ` Sean Christopherson
2022-01-14  2:58                   ` Chao Gao
2022-01-14  8:17                     ` Maxim Levitsky
2022-01-17  3:17                       ` Chao Gao
2022-02-02 23:23                   ` Sean Christopherson
2022-02-03 20:22                     ` Sean Christopherson
2022-02-23  6:10                       ` Chao Gao
2022-02-23 10:26                         ` Maxim Levitsky
2022-01-14  0:22               ` Yuan Yao
2021-12-31 14:28 ` [PATCH v5 8/8] KVM: VMX: Resize PID-ponter table on demand for IPI virtualization Zeng Guang
2022-01-13 22:09   ` Sean Christopherson
2022-01-14 15:59     ` Zeng Guang
2022-01-14 16:18       ` Sean Christopherson
2022-01-17 15:04         ` Zeng Guang
2022-01-18 17:15           ` Sean Christopherson
2022-01-19  7:55             ` Zeng Guang
2022-01-20  1:01               ` Sean Christopherson
2022-01-24 16:40                 ` Zeng Guang

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=a46ce4d0-adfc-b149-e3aa-8b2f39e76e28@intel.com \
    --to=guang.zeng@intel.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=jethro@fortanix.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kai.huang@intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kim.phillips@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.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: 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.