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

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, July 03, 2014 2:50 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Sander Eikelenboom; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] Bisected Xen-unstable: "Segment register inaccessible
> for d1v0" when starting HVM guest on intel
> 
> >>> 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).

Need more time to think about how to handle case 2. If we need guest's hint,
can we get it from 'VCPUOP_register_vcpu_time_memory_area' hypercall ?

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

So 
For case 1, the guest virtual address should be a in guest supervisor-only 
accessible page,
We need to do the SMAP check, if the guest virtual address happens to be a 
user-accessible
one, an SMAP violation happens

For case 2, the guest virtual address may be a user-accessible one, but this is 
intended
by the guest, so we need some hints from the guest to determine how to handle 
it.

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

This is a little complicated to me right now, may need more investigation
on it to find whether I can understand this!

Thanks,
Feng

> 
> Jan


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