[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 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). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |