[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
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |