[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Question about VPID during MOV-TO-CR3
On Sep 22, 2016 03:00, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>
> >>> On 21.09.16 at 20:26, <tamas.lengyel@xxxxxxxxxxxx> wrote:
> > So reading through the Intel SDM the following bits are relevant here:
> >
> > 28.3.3.1
> > Operations that Invalidate Cached Mappings
> > The following operations invalidate cached mappings as indicated:
> > ● Operations that architecturally invalidate entries in the TLBs or
> > paging-structure caches independent of VMX
> > operation (e.g., the INVLPG and INVPCID instructions) invalidate
> > linear mappings and combined mappings. 1
> > They are required to do so only for the current VPID (but, for
> > combined mappings, all EP4TAs). Linear
> > mappings for the current VPID are invalidated even if EPT is in use. 2
> > Combined mappings for the current
> > VPID are invalidated even if EPT is not in use.
> >
> > To me this reads that the CPU will automatically handle the TLB
> > flushing for all operations that would normally do so when running
> > without a hypervisor, but only within the context of the VPID. While
> > it doesn't list MOV-TO-CR3 specifically, I'm sure it falls into this
> > same category regarding non-global TLB entries that would be flushed
> > by it. Thus, there is no need for the VMM to step in do anything in
> > this regard if my interpretation is correct.
>
> Well, that would be true if a CR3 write intercept meant the CPU
> first does its job, and only then invokes the hypervisor. Such
> intercepts, however, get invoked before the CPU starts doing
> anything the instruction would require to be done (except for
> a few exception checks, like CPL). Hence the hypervisor has to
> do everything the CPU would normally do on its own.
>
Has that been verified though? The SDM doesn't mention that cpu-based load exiting would alter the TLB operations the CPU would otherwise perform. So while I could see this actually being the case I can't find anything officially saying this.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
