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: > > > > 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@lists.xen.org https://lists.xen.org/xen-devel
