On Sep 22, 2016 03:00, "Jan Beulich" <jbeul...@suse.com> wrote:
> >>> On 21.09.16 at 20:26, <tamas.leng...@zentific.com> wrote:
> > So reading through the Intel SDM the following bits are relevant here:
> >
> >
> > 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.

Xen-devel mailing list

Reply via email to