mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>, kvm@vger.kernel.org
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	linux-kernel@vger.kernel.org, "Jim Mattson" <jmattson@google.com>
Subject: Re: [PATCH] x86/kvm/lapic: always disable MMIO interface in x2APIC mode
Date: Fri, 14 Sep 2018 19:21:22 +0200	[thread overview]
Message-ID: <cd2619b9-52d9-9cf6-9ec1-8b7f014321ea@redhat.com> (raw)
In-Reply-To: <20180802150816.18374-1-vkuznets@redhat.com>

On 02/08/2018 17:08, Vitaly Kuznetsov wrote:
> When VMX is used with flexpriority disabled (because of no support or
> if disabled with module parameter) MMIO interface to lAPIC is still
> available in x2APIC mode while it shouldn't be (kvm-unit-tests):
> 
> PASS: apic_disable: Local apic enabled in x2APIC mode
> PASS: apic_disable: CPUID.1H:EDX.APIC[bit 9] is set
> FAIL: apic_disable: *0xfee00030: 50014
> 
> The issue appears because we basically do nothing while switching to
> x2APIC mode when APIC access page is not used. apic_mmio_{read,write}
> only check if lAPIC is disabled before proceeding to actual write.
> 
> When APIC access is virtualized we correctly manipulate with VMX controls
> in vmx_set_virtual_apic_mode() and we don't get vmexits from memory writes
> in x2APIC mode so there's no issue.
> 
> Disabling MMIO interface seems to be easy. The question is: what do we
> do with these reads and writes? If we add apic_x2apic_mode() check to
> apic_mmio_in_range() and return -EOPNOTSUPP these reads and writes will
> go to userspace. When lAPIC is in kernel, Qemu uses this interface to
> inject MSIs only (see kvm_apic_mem_write() in hw/i386/kvm/apic.c). This
> somehow works with disabled lAPIC but when we're in xAPIC mode we will
> get a real injected MSI from every write to lAPIC. Not good.
> 
> The simplest solution seems to be to just ignore writes to the region
> and return ~0 for all reads when we're in x2APIC mode. This is what this
> patch does. However, this approach is inconsistent with what currently
> happens when flexpriority is enabled: we allocate APIC access page and
> create KVM memory region so in x2APIC modes all reads and writes go to
> this pre-allocated page which is, btw, the same for all vCPUs.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> Changes since RFC:
> - add KVM_X86_QUIRK_LAPIC_MMIO_HOLE disabling the newly introduced
>   'MMIO hole' behavior [Paolo Bonzini]
> ---
>  arch/x86/include/uapi/asm/kvm.h |  1 +
>  arch/x86/kvm/lapic.c            | 22 +++++++++++++++++++---
>  2 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> index 86299efa804a..fd23d5778ea1 100644
> --- a/arch/x86/include/uapi/asm/kvm.h
> +++ b/arch/x86/include/uapi/asm/kvm.h
> @@ -377,6 +377,7 @@ struct kvm_sync_regs {
>  
>  #define KVM_X86_QUIRK_LINT0_REENABLED	(1 << 0)
>  #define KVM_X86_QUIRK_CD_NW_CLEARED	(1 << 1)
> +#define KVM_X86_QUIRK_LAPIC_MMIO_HOLE	(1 << 2)
>  
>  #define KVM_STATE_NESTED_GUEST_MODE	0x00000001
>  #define KVM_STATE_NESTED_RUN_PENDING	0x00000002
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index b5cd8465d44f..83c4e8cc7eb9 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -1291,9 +1291,8 @@ EXPORT_SYMBOL_GPL(kvm_lapic_reg_read);
>  
>  static int apic_mmio_in_range(struct kvm_lapic *apic, gpa_t addr)
>  {
> -	return kvm_apic_hw_enabled(apic) &&
> -	    addr >= apic->base_address &&
> -	    addr < apic->base_address + LAPIC_MMIO_LENGTH;
> +	return addr >= apic->base_address &&
> +		addr < apic->base_address + LAPIC_MMIO_LENGTH;
>  }
>  
>  static int apic_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *this,
> @@ -1305,6 +1304,15 @@ static int apic_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *this,
>  	if (!apic_mmio_in_range(apic, address))
>  		return -EOPNOTSUPP;
>  
> +	if (!kvm_apic_hw_enabled(apic) || apic_x2apic_mode(apic)) {
> +		if (!kvm_check_has_quirk(vcpu->kvm,
> +					 KVM_X86_QUIRK_LAPIC_MMIO_HOLE))
> +			return -EOPNOTSUPP;
> +
> +		memset(data, 0xff, len);
> +		return 0;
> +	}
> +
>  	kvm_lapic_reg_read(apic, offset, len, data);
>  
>  	return 0;
> @@ -1864,6 +1872,14 @@ static int apic_mmio_write(struct kvm_vcpu *vcpu, struct kvm_io_device *this,
>  	if (!apic_mmio_in_range(apic, address))
>  		return -EOPNOTSUPP;
>  
> +	if (!kvm_apic_hw_enabled(apic) || apic_x2apic_mode(apic)) {
> +		if (!kvm_check_has_quirk(vcpu->kvm,
> +					 KVM_X86_QUIRK_LAPIC_MMIO_HOLE))
> +			return -EOPNOTSUPP;
> +
> +		return 0;
> +	}
> +
>  	/*
>  	 * APIC register must be aligned on 128-bits boundary.
>  	 * 32/64/128 bits registers must be accessed thru 32 bits.
> 

Queued, thanks.

Paolo

      reply	other threads:[~2018-09-14 17:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 15:08 Vitaly Kuznetsov
2018-09-14 17:21 ` Paolo Bonzini [this message]

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=cd2619b9-52d9-9cf6-9ec1-8b7f014321ea@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rkrcmar@redhat.com \
    --cc=vkuznets@redhat.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

all inboxes | Powered by JetHome®