>>> On 21.09.16 at 16:18, <tamas.leng...@zentific.com> wrote:
> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>>> On 20.09.16 at 19:29, <tamas.leng...@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?
Are you forgetting that a move to CR3 needs to flush all non-global
TLB entries? Or else, why do you think no flushing needs to happen
> 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.
Xen-devel mailing list