Re: [Xen-devel] Weekly VMX status report. Xen: #18846 & Xen0: #749

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 12/12/2008 20:37, "Gianluca Guida" <gianluca.guida@xxxxxxxxxxxxx> wrote:

> - Disable NX support in shadows until all vcpus have EFER's NX enabled.
> This would means that the guest thinks it has NX bit protection in at
> least one vcpus but in reality it doesn't. Also, to properly support
> execute-disable protection, we would need to blow the shadows when we
> can finally enable NX bit in shadows.
> 
> - Always enable EFER's NX in host mode. We could also avoid changing
> EFER's status between vmentry and vmexits, but this would cause some
> issue in reserved bit handling in page faults. This could be easily
> fixed in shadow code, but in HAP would make the whole thing more
> complicated.
> 
> Do the people that know better than me the actual VMX code have any
> opinion about the best way to fix this?

Is there any guest that actually cares about having EFER_NX really cleared?
Presumably the only way of detecting this would be reserved-bit page faults,
which no OS is likely to want to deliberately cause?

There's been some talk of NX'ing up Xen's data areas. In that case we
*would* need NX enabled always in host mode. Would it actually be worth
enabling/disabling on vmexit/vmentry?

SVM actually does automatically save/restore EFER on vmentry/vmexit. Could
we use VMX's MSR load/save support for the same effect? Would it be slow, or
interact badly with the existing support for switching EFER.LME?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel