[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 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.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.