All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Mohammed Gamal <mgamal@redhat.com>, kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, vkuznets@redhat.com,
	sean.j.christopherson@intel.com, wanpengli@tencent.com,
	jmattson@google.com, joro@8bytes.org,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Babu Moger <babu.moger@amd.com>
Subject: Re: [PATCH v3 9/9] KVM: x86: SVM: VMX: Make GUEST_MAXPHYADDR < HOST_MAXPHYADDR support configurable
Date: Fri, 10 Jul 2020 19:40:45 +0200	[thread overview]
Message-ID: <c01fb991-8352-53be-3aab-8de808ead5ea@redhat.com> (raw)
In-Reply-To: <20200710154811.418214-10-mgamal@redhat.com>

On 10/07/20 17:48, Mohammed Gamal wrote:
> The reason behind including this patch is unexpected behaviour we see
> with NPT vmexit handling in AMD processor.
> 
> With previous patch ("KVM: SVM: Add guest physical address check in
> NPF/PF interception") we see the followning error multiple times in
> the 'access' test in kvm-unit-tests:
> 
>             test pte.p pte.36 pde.p: FAIL: pte 2000021 expected 2000001
>             Dump mapping: address: 0x123400000000
>             ------L4: 24c3027
>             ------L3: 24c4027
>             ------L2: 24c5021
>             ------L1: 1002000021
> 
> This shows that the PTE's accessed bit is apparently being set by
> the CPU hardware before the NPF vmexit. This completely handled by
> hardware and can not be fixed in software.
> 
> This patch introduces a workaround. We add a boolean variable:
> 'allow_smaller_maxphyaddr'
> Which is set individually by VMX and SVM init routines. On VMX it's
> always set to true, on SVM it's only set to true when NPT is not
> enabled.
> 
> We also add a new capability KVM_CAP_SMALLER_MAXPHYADDR which
> allows userspace to query if the underlying architecture would
> support GUEST_MAXPHYADDR < HOST_MAXPHYADDR and hence act accordingly
> (e.g. qemu can decide if it would ignore the -cpu ..,phys-bits=X)
> 
> CC: Tom Lendacky <thomas.lendacky@amd.com>
> CC: Babu Moger <babu.moger@amd.com>
> Signed-off-by: Mohammed Gamal <mgamal@redhat.com>

Slightly rewritten commit message:

    KVM: x86: Add a capability for GUEST_MAXPHYADDR < HOST_MAXPHYADDR support
    
    This patch adds a new capability KVM_CAP_SMALLER_MAXPHYADDR which
    allows userspace to query if the underlying architecture would
    support GUEST_MAXPHYADDR < HOST_MAXPHYADDR and hence act accordingly
    (e.g. qemu can decide if it should warn for -cpu ..,phys-bits=X)
    
    The complications in this patch are due to unexpected (but documented)
    behaviour we see with NPF vmexit handling in AMD processor.  If
    SVM is modified to add guest physical address checks in the NPF
    and guest #PF paths, we see the followning error multiple times in
    the 'access' test in kvm-unit-tests:
    
                test pte.p pte.36 pde.p: FAIL: pte 2000021 expected 2000001
                Dump mapping: address: 0x123400000000
                ------L4: 24c3027
                ------L3: 24c4027
                ------L2: 24c5021
                ------L1: 1002000021
    
    This is because the PTE's accessed bit is set by the CPU hardware before
    the NPF vmexit. This is handled completely by hardware and cannot be fixed
    in software.
    
    Therefore, availability of the new capability depends on a boolean variable
    allow_smaller_maxphyaddr which is set individually by VMX and SVM init
    routines. On VMX it's always set to true, on SVM it's only set to true
    when NPT is not enabled.
    
    CC: Tom Lendacky <thomas.lendacky@amd.com>
    CC: Babu Moger <babu.moger@amd.com>
    Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
    Message-Id: <20200710154811.418214-10-mgamal@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo


  reply	other threads:[~2020-07-10 17:40 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 15:48 [PATCH v3 0/9] KVM: Support guest MAXPHYADDR < host MAXPHYADDR Mohammed Gamal
2020-07-10 15:48 ` [PATCH v3 1/9] KVM: x86: Add helper functions for illegal GPA checking and page fault injection Mohammed Gamal
2020-07-10 15:48 ` [PATCH v3 2/9] KVM: x86: mmu: Move translate_gpa() to mmu.c Mohammed Gamal
2020-07-10 15:48 ` [PATCH v3 3/9] KVM: x86: mmu: Add guest physical address check in translate_gpa() Mohammed Gamal
2020-07-10 17:41   ` Paolo Bonzini
2020-07-10 15:48 ` [PATCH v3 4/9] KVM: x86: rename update_bp_intercept to update_exception_bitmap Mohammed Gamal
2020-07-10 16:15   ` Jim Mattson
2020-07-10 15:48 ` [PATCH v3 5/9] KVM: x86: update exception bitmap on CPUID changes Mohammed Gamal
2020-07-10 16:25   ` Jim Mattson
2020-07-10 15:48 ` [PATCH v3 6/9] KVM: VMX: introduce vmx_need_pf_intercept Mohammed Gamal
2020-07-10 15:48 ` [PATCH v3 7/9] KVM: VMX: Add guest physical address check in EPT violation and misconfig Mohammed Gamal
2020-07-13 18:32   ` Sean Christopherson
2020-07-15 23:00   ` Sean Christopherson
2020-08-17 17:22     ` Sean Christopherson
2020-08-17 18:01       ` Paolo Bonzini
2020-10-09 16:17   ` Jim Mattson
2020-10-14 23:44     ` Jim Mattson
2020-10-23  3:14       ` Sean Christopherson
2020-10-23  9:22         ` Paolo Bonzini
2020-10-23 16:59           ` Jim Mattson
2020-10-23 17:16             ` Paolo Bonzini
2020-10-23 17:23               ` Jim Mattson
2020-10-23 17:43                 ` Paolo Bonzini
2021-01-15 19:35                   ` Jim Mattson
2021-01-20 21:16                     ` Jim Mattson
2021-01-27 20:57                       ` Jim Mattson
2021-06-21 18:31                         ` Jim Mattson
2020-07-10 15:48 ` [PATCH v3 8/9] KVM: VMX: optimize #PF injection when MAXPHYADDR does not match Mohammed Gamal
2020-07-10 15:48 ` [PATCH v3 9/9] KVM: x86: SVM: VMX: Make GUEST_MAXPHYADDR < HOST_MAXPHYADDR support configurable Mohammed Gamal
2020-07-10 17:40   ` Paolo Bonzini [this message]
2020-07-10 16:30 ` [PATCH v3 0/9] KVM: Support guest MAXPHYADDR < host MAXPHYADDR Jim Mattson
2020-07-10 17:06   ` Paolo Bonzini
2020-07-10 17:13     ` Jim Mattson
2020-07-10 17:16       ` Paolo Bonzini
2020-07-10 17:26         ` Sean Christopherson
2020-07-10 17:26         ` Jim Mattson
2020-07-10 17:40           ` Paolo Bonzini
2020-07-10 17:49 ` 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=c01fb991-8352-53be-3aab-8de808ead5ea@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=babu.moger@amd.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgamal@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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.