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

I am not familiar with these related code actually, I try to get some
findings in the code, but seems no good news. So maybe I have some
basic questions here:
1. What is the purpose of 'struct arch_vcpu_info arch'?
2. Do you mean I can use the member 'unsigned long pad' of it to tell
the guest about the dropped write.
3. What information about the dropped write should be sent to guest?
4. When guests will poll the information?
5. Can vIRQ be used for HVM guest? Is there an existing example in the
current code?

Appreciate the time you put on this to clarify things to me!

Thanks,
Feng

> 
> Jan


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