Re: [Xen-devel] Bisected Xen-unstable: "Segment register inaccessible for d1v0" when starting HVM guest on intel

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.07.14 at 08:15, <feng.wu@xxxxxxxxx> wrote:
> After thinking a little more about what you said in this thread, here is the 
> basic ideas
> I get about this PV extension:
> 1. With this PV extension, when Xen tries to access guest memory for 
> non-emulation
> purpose, we always treat this access as a supervisor mode.

The fact that these accesses are to be consider supervisor mode ones
goes without saying. The question is how to treat them when SMAP is
enabled: As said before, while the runstate area update clearly should
always be subject to validation, for the secondary time area update
it needs to be investigated (possibly the guest needs to be given
control over what it wants the behavior to be).

> 2. We need always do SMAP checking for those Xen accesses when SMAP is 
> enabled by
> the HVM guests. However, if the guest is actually running in Ring 0 and 
> X86_EFLAGS_AC
> bit is set by it, if we got an SMAP violation while doing the SMAP check, is 
> this overkilled?

The point is that these accesses are asynchronous (i.e. the
guest can't know when they will happen), and hence making them
dependent on current guest state would be bogus (I listed this as
an option earlier irrespective of that).

And as Andrew emphasized, raising a fault in response to a failure
here is out of question (the only two options considering this is
asynchronous would be #MC or a failsafe callback, neither of which
really fit the purpose). Nevertheless it would be rather desirable to
have a way to tell the guest about the dropped write. We've got
a field in struct arch_vcpu_info that we could leverage for this,
requiring the guest to actively poll if it cares about finding out (to
avoid the polling this could further be combined with a new
per-vCPU vIRQ, or by defining another XEN_NMIREASON_* value
and delivering the notification via NMI).

Jan


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