Re: Question about VPID during MOV-TO-CR3

[Tamas K Lengyel <tamas.lengyel@zentific.com>]

On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.09.16 at 19:29, <tamas.lengyel@zentific.com> wrote:
>> I'm trying to figure out the design decision regarding the handling of
>> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
>> VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
>> (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
>> hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
>> TLB utilization point-of-view this seems to be rather wasteful.
>> Furthermore, it even breaks the guests' ability to take advantage of
>> PCID, as the TLB just guts flushed when a new process is scheduled.
>> Does anyone have an insight into what was the rationale behind this?
>
> Since you don't quote the specific commit(s), I would guess that
> this was mainly an attempt by the author(s) to keep things simple
> for themselves, i.e. not having to properly think through under
> which conditions less than a full TLB flush would suffice.

The commit that added VPID and the TLB flush is
e2cf9bd6e055ea678da129b776f4521f6a0b50fe x86, vmx: Enable VPID
(Virtual Processor Identification). So this has been there as long as
Xen supported VPID. The only case where flushing the TLB on a guest
MOV-TO-CR3 that possibly would make sense to me is if we are running a
PV guest. But this is hvm/vmx, so why would we care about what the
guest does to its cr3 from a TLB standpoint? Wouldn't the guest OS
need be in charge of that? With the TLBs being tagged there is no
side-effect the guest can induce on any other domain whether it
flushes its TLB or not.

Tamas

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