Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 23.09.16 at 17:26, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 22.09.16 at 19:18, <tamas.lengyel@xxxxxxxxxxxx> 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.
>
> This late? According to the CR0 handling in
> vmx_update_guest_cr() I would understand it to be enabled only
> while the guest is still in real mode (and even then only on old
> hardware, i.e. without the Unrestricted Guest functionality).
>

Right, with unrestricted guest support I would assume none of this
would get called - but it does, and quite frequently during domain
boot. The CPU is a Intel(R) Xeon(R) CPU E5-2430.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel