[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Question about VPID during MOV-TO-CR3
>>> On 21.09.16 at 16:18, <tamas.lengyel@xxxxxxxxxxxx> wrote: > On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>> On 20.09.16 at 19:29, <tamas.lengyel@xxxxxxxxxxxx> 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 at all? Jan > 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |