All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Christoph Egger <chegger@amazon.de>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: hap_invlpg() vs INVLPGA
Date: Mon, 01 Feb 2016 02:58:44 -0700	[thread overview]
Message-ID: <56AF3A6502000078000CCD61@prv-mh.provo.novell.com> (raw)
In-Reply-To: <56AF2832.2010801@amazon.de>

>>> On 01.02.16 at 10:41, <chegger@amazon.de> wrote:
> On 01/02/16 10:00, Jan Beulich wrote:
>>>>> On 01.02.16 at 09:14, <chegger@amazon.de> wrote:
>>> On 01/02/16 09:04, Jan Beulich wrote:
>>>>>> This, otoh, reads as if you imply we intercept the L2's INVLPG.
>>>>>> Yet the INVLPG intercept gets cleared when the domain uses
>>>>>> NPT (and your original change also didn't alter any intercept
>>>>>> settings). Hence I'm still lost how hap_invlpg() can be reached
>>>>>> in that case other than via emulating INVLPG in the instruction
>>>>>> emulator.
>>>>>
>>>>> svm_invlpg_intercept() and vmx_invlpg_intercept() call
>>>>> paging_invlpg().  paging_invlpg() calls hap_invlpg()
>>>>> as initialized in xen/arch/x86/mm/hap/hap.c
>>>>
>>>> That's all fine, but according to my previous reply: How does
>>>> execution reach svm_invlpg_intercept() when the INVLPG
>>>> intercept gets disabled for domains using HAP (NPT)?
>>>
>>> The intercept bitmask for L1 guest and L2 guest gets binary or'ed
>>> when emulating the VMENTRY for the L1 guest.
>>> That way you get also intercepts for the L1 hypervisor.
>> 
>> Okay, I can see this perhaps being correct (albeit unexpected)
>> for general1-intercepts (because all 32 bits are defined), but
>> clearly this is broken for e.g. general2-intercepts (where the
>> guest could set flags the hypervisor doesn't know about),
>> leading to the BUG() in nsvm_vmcb_guest_intercepts_exitcode().
>> Hence I didn't expect such behavior to be there in the first place.
> 
> Whenever new intercepts get defined then those must be added.

I'm sorry, but no - this attitude is why nested mode can't be
expected to become supported any time soon. Unknown intercepts
must be explicitly filtered out and/or unknown L2 exits must be
handled gracefully (to at least the hypervisor).

>> And then this still doesn't make svm_invlpg_intercept() reachable:
>> While the L2 guest runs, the INVLPG intercept would be reflected
>> to the L1 guest. Whereas while the L1 guest runs, the intercept
>> would be off.
> 
> While this is correct, L0 hypervisor must flush the nested hap or
> whatever the L1 hypervisor does has no real effect to the L2 guest,
> otherwise because the TLB/MMU pagetable walk is not different.

I don't understand: You agree that svm_invlpg_intercept() is
unreachable when the guest uses HAP, but at the same time
you say that what it does is required for correct operation?

Jan

      reply	other threads:[~2016-02-01  9:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29 13:24 hap_invlpg() vs INVLPGA Jan Beulich
2016-01-29 13:57 ` Egger, Christoph
2016-01-29 14:02   ` Egger, Christoph
2016-01-29 15:53     ` Jan Beulich
2016-01-29 17:09       ` Egger, Christoph
2016-02-01  8:04         ` Jan Beulich
2016-02-01  8:14           ` Egger, Christoph
2016-02-01  9:00             ` Jan Beulich
2016-02-01  9:41               ` Egger, Christoph
2016-02-01  9:58                 ` Jan Beulich [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=56AF3A6502000078000CCD61@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=chegger@amazon.de \
    --cc=xen-devel@lists.xenproject.org \
    /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.