[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain
On Mon, Mar 13, 2017 at 05:48:44AM -0600, Jan Beulich wrote: > >>> On 10.03.17 at 18:10, <andrew.cooper3@xxxxxxxxxx> wrote: > > On 28/02/17 09:31, Jan Beulich wrote: > >>>>> On 27.02.17 at 16:10, <andrew.cooper3@xxxxxxxxxx> wrote: > >>> On 22/02/17 10:10, Jan Beulich wrote: > >>>>>>> On 22.02.17 at 11:00, <andrew.cooper3@xxxxxxxxxx> wrote: > >>>>> On 22/02/17 09:23, Jan Beulich wrote: > >>>>>>>>> On 20.02.17 at 12:00, <andrew.cooper3@xxxxxxxxxx> wrote: > >>>>>>> The domain builder in libxc no longer depends on leaked CPUID > >>>>>>> information to > >>>>>>> properly construct HVM domains. Remove the control domain exclusion. > >>>>>> Am I missing some intermediate step? As long as there's a raw > >>>>>> CPUID invocation in xc_cpuid_x86.c (which is still there in staging > >>>>>> and I don't recall this series removing it) it at least _feels_ unsafe. > >>>>> Strictly speaking, the domain builder part of this was completed after > >>>>> my xsave adjustments. All the guest-type-dependent information now > >>>>> comes from non-cpuid sources in libxc, or Xen ignores the toolstack > >>>>> values and recalculates information itself. > >>>>> > >>>>> However, until the Intel leaves were complete, dom0 had a hard time > >>>>> booting with this change as there were no toolstack-provided policy and > >>>>> no leakage from hardware. > >>>> So what are the CPUID uses in libxc then needed for at this point? > >>>> Could they be removed in a prereq patch to make clear all needed > >>>> information is now being obtained via hypercalls? > >>> I'd prefer to defer that work. The next chunk of CPUID work is going to > >>> be redesigning and reimplementing the hypervisor/libxc interface, and > >>> all cpuid() calls in libxc will fall out there, but its not a trivial > >>> set of changes to make. > >> With that, could you live with deferring the patch here until then? > > > > We currently have a lot of dom0 implicit dependencies on leaked CPUID > > state into PV dom0. > > > > With this series, I believe I have identified all leaked dependencies, > > and I really want to prevent is introducing any new implicit dependences > > accidentally. > > I can certainly understand this, but the state libxc code is in then > makes this a rather implicit thing, instead of being fully explicit. I > think I'd like to have another (tools or REST) maintainer voice a 3rd > opinion. Extending Cc list ... > I'm not sure I follow the implicit vs explicit bit. Wei. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |