From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: Question about VPID during MOV-TO-CR3
Date: Fri, 23 Sep 2016 09:26:14 -0600 [thread overview]
Message-ID: <CAErYnshOVHBaFQCdPZHMU8hqfS67wM85u=NPKYt5m0_w_JvSzg@mail.gmail.com> (raw)
In-Reply-To: <57E502C60200007800111D86@prv-mh.provo.novell.com>
On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 22.09.16 at 19:18, <tamas.lengyel@zentific.com> wrote:
>> So I verified that when CPU-based load exiting is enabled, the TLB
>> flush here is critical. Without it the guest kernel crashes at random
>> points during boot. OTOH why does Xen trap every guest CR3 update
>> unconditionally? While we have features such as the vm_event/monitor
>> that may choose to subscribe to that event, Xen traps it even when
>> that is not in use. Is that trapping necessary for something else?
>
> Where do you see this being unconditional? construct_vmcs()
> clearly avoids setting these intercepts when using EPT. Are you
> perhaps suffering from
>
> /* Trap CR3 updates if CR3 memory events are enabled. */
> if ( v->domain->arch.monitor.write_ctrlreg_enabled &
> monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
> v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
>
> in vmx_update_guest_cr()? That'll be rather something for you
> or Razvan to explain. Outside of nested VMX I don't see any
> other enabling of that intercept (didn't check AMD code on the
> assumption that you're working on Intel hardware).
So there seems to be two separate paths that lead to the TLB flushing.
One is indeed the above case you cited when we enable CR3 monitoring
through the monitor interface. However, during domain boot I also see
this path being called that is not related to the
CPU_BASED_CR3_LOAD_EXITING:
(XEN) hap.c:739:d1v0 hap_update_paging_modes is calling hap_update_cr3
(XEN) hap.c:701:d1v0 HAP update cr3 called
(XEN) /src/xen/xen/include/asm/hvm/hvm.h:344:d1v0 HVM update guest cr3 called
(XEN) vmx.c:1549:d1v0 Update guest CR3 value=0x7a7c4000
This path seems to de-activate once the domain is fully booted. So at
this point I'm still not sure if the CPU-based load exiting needs the
flush or not, as I couldn't get the domain to boot when the flush was
simply removed, as this other path does seem to require it. I'll do an
experiment with the tlb flush only happening if the monitor interface
for this is not enabled and see what happens.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-09-23 15:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 17:29 Question about VPID during MOV-TO-CR3 Tamas K Lengyel
2016-09-21 10:23 ` Jan Beulich
2016-09-21 14:18 ` Tamas K Lengyel
2016-09-21 14:44 ` Jan Beulich
2016-09-21 15:09 ` Tamas K Lengyel
2016-09-21 15:16 ` Tamas K Lengyel
2016-09-21 15:23 ` Jan Beulich
2016-09-21 15:30 ` Tamas K Lengyel
2016-09-21 18:26 ` Tamas K Lengyel
2016-09-22 9:00 ` Jan Beulich
2016-09-22 10:39 ` Tamas K Lengyel
2016-09-22 11:35 ` Jan Beulich
2016-09-22 8:56 ` Jan Beulich
2016-09-22 10:35 ` Tamas K Lengyel
2016-09-22 11:27 ` Jan Beulich
2016-09-22 11:37 ` Tamas K Lengyel
2016-09-22 17:18 ` Tamas K Lengyel
2016-09-23 8:24 ` Jan Beulich
2016-09-23 8:35 ` Razvan Cojocaru
2016-09-23 15:26 ` Tamas K Lengyel [this message]
2016-09-23 15:39 ` Jan Beulich
2016-09-23 15:50 ` Tamas K Lengyel
2016-09-23 20:45 ` Tamas K Lengyel
2016-09-26 6:24 ` Jan Beulich
2016-09-26 16:12 ` Tamas K Lengyel
2016-09-27 13:49 ` Jan Beulich
2016-10-01 19:05 ` Tamas K Lengyel
2016-10-04 7:41 ` Jan Beulich
2016-10-04 14:12 ` Tamas K Lengyel
2016-10-04 14:29 ` Jan Beulich
2016-10-04 15:06 ` Tim Deegan
2016-10-07 15:32 ` Jan Beulich
2016-10-07 15:41 ` Tamas K Lengyel
2016-10-07 16:00 ` Jan Beulich
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='CAErYnshOVHBaFQCdPZHMU8hqfS67wM85u=NPKYt5m0_w_JvSzg@mail.gmail.com' \
--to=tamas.lengyel@zentific.com \
--cc=JBeulich@suse.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).