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 4:59 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 10:17, <feng.wu@xxxxxxxxx> wrote:
> 
> >
> >> -----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 ?
> 
> Obviously not, as there's no room in the hypercall argument to pass
> that information.

Do you have any ideas about how to get this kind of information from guests?

> 
> Also it's not clear to me in this context what "case 2" you refer to above.

Sorry, 'Case 2' means the 'secondary time area update' case.

> 
> >> > 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.
> 
> "how" is probably the wrong term here, since "how" only (and directly)
> depends on whether the VA is a user visible one.

Okay, here I mean how the guest want us to handle it, do the checking or not.

Thanks,
Feng

> 
> Jan


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