All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Yang Weijiang <weijiang.yang@intel.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	sean.j.christopherson@intel.com
Cc: mst@redhat.com, rkrcmar@redhat.com, jmattson@google.com,
	yu.c.zhang@intel.com, alazar@bitdefender.com
Subject: Re: [PATCH RESEND v4 7/9] KVM: VMX: Handle SPP induced vmexit and page fault
Date: Mon, 19 Aug 2019 17:04:23 +0200	[thread overview]
Message-ID: <fb6cd8b4-eee9-6e58-4047-550811bffd58@redhat.com> (raw)
In-Reply-To: <5f6ba406-17c4-a552-2352-2ff50569aac0@redhat.com>

On 19/08/19 16:43, Paolo Bonzini wrote:
>> +			/*
>> +			 * Record write protect fault caused by
>> +			 * Sub-page Protection, let VMI decide
>> +			 * the next step.
>> +			 */
>> +			if (spte & PT_SPP_MASK) {
> Should this be "if (spte & PT_WRITABLE_MASK)" instead?  That is, if the
> page is already writable, the fault must be an SPP fault.

Hmm, no I forgot how SPP works; still, this is *not* correct.  For
example, if SPP marks part of a page as read-write, but KVM wants to
write-protect the whole page for access or dirty tracking, that should
not cause an SPP exit.

So I think that when KVM wants to write-protect the whole page
(wrprot_ad_disabled_spte) it must also clear PT_SPP_MASK; for example it
could save it in bit 53 (PT64_SECOND_AVAIL_BITS_SHIFT + 1).  If the
saved bit is set, fast_page_fault must then set PT_SPP_MASK instead of
PT_WRITABLE_MASK.  On re-entry this will cause an SPP vmexit;
fast_page_fault should never trigger an SPP userspace exit on its own,
all the SPP handling should go through handle_spp.

Paolo

  reply	other threads:[~2019-08-19 15:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14  7:03 [PATCH RESEND v4 0/9] Enable Sub-page Write Protection Support Yang Weijiang
2019-08-14  7:03 ` [PATCH RESEND v4 1/9] Documentation: Introduce EPT based Subpage Protection Yang Weijiang
2019-08-14  7:03 ` [PATCH RESEND v4 2/9] KVM: VMX: Add control flags for SPP enabling Yang Weijiang
2019-08-14  7:03 ` [PATCH RESEND v4 3/9] KVM: VMX: Implement functions for SPPT paging setup Yang Weijiang
2019-08-14  7:03 ` [PATCH RESEND v4 4/9] KVM: VMX: Introduce SPP access bitmap and operation functions Yang Weijiang
2019-08-14  7:03 ` [PATCH RESEND v4 5/9] KVM: VMX: Add init/set/get functions for SPP Yang Weijiang
2019-08-14 12:43   ` Vitaly Kuznetsov
2019-08-14 14:34     ` Yang Weijiang
2019-08-15 13:43     ` Yang Weijiang
2019-08-15 14:03       ` Vitaly Kuznetsov
2019-08-19 14:06         ` Yang Weijiang
2019-08-15 16:25       ` Jim Mattson
2019-08-15 16:38         ` Sean Christopherson
2019-08-16 13:31           ` Yang Weijiang
2019-08-16 18:19             ` Jim Mattson
2019-08-19  2:08               ` Yang Weijiang
2019-08-19 15:15                 ` Paolo Bonzini
2019-08-20 12:33                   ` Yang Weijiang
2019-08-19 15:05   ` Paolo Bonzini
2019-08-20 12:36     ` Yang Weijiang
2019-08-19 15:13   ` Paolo Bonzini
2019-08-20 13:09     ` Yang Weijiang
2019-08-14  7:04 ` [PATCH RESEND v4 6/9] KVM: VMX: Introduce SPP user-space IOCTLs Yang Weijiang
2019-08-14  7:04 ` [PATCH RESEND v4 7/9] KVM: VMX: Handle SPP induced vmexit and page fault Yang Weijiang
2019-08-19 14:43   ` Paolo Bonzini
2019-08-19 15:04     ` Paolo Bonzini [this message]
2019-08-20 13:44       ` Yang Weijiang
2019-08-22 13:17         ` Yang Weijiang
2019-08-22 16:38           ` Paolo Bonzini
2019-08-23  0:26             ` Yang Weijiang
2019-08-14  7:04 ` [PATCH RESEND v4 8/9] KVM: MMU: Enable Lazy mode SPPT setup Yang Weijiang
2019-08-19 14:46   ` Paolo Bonzini
2019-08-20 13:12     ` Yang Weijiang
2019-09-04 13:49       ` Yang Weijiang
2019-09-09 17:10         ` Paolo Bonzini
2019-09-11  0:23           ` Yang Weijiang
2019-08-14  7:04 ` [PATCH RESEND v4 9/9] KVM: MMU: Handle host memory remapping and reclaim Yang Weijiang
2019-08-14 12:36 ` [PATCH RESEND v4 0/9] Enable Sub-page Write Protection Support Paolo Bonzini
2019-08-14 14:02   ` Yang Weijiang
2019-08-14 14:06     ` 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=fb6cd8b4-eee9-6e58-4047-550811bffd58@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alazar@bitdefender.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=weijiang.yang@intel.com \
    --cc=yu.c.zhang@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.