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

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

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

Jan


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