[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Bisected Xen-unstable: "Segment register inaccessible for d1v0" when starting HVM guest on intel
> -----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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |