Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.03.17 at 16:06, <wei.liu2@xxxxxxxxxx> wrote:
> 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.

Right now libxc still uses the CPUID instruction, thus implicitly (via
CPUID faulting / masking) obtaining the intended (filtered) state of
individual feature flags. The intended explicit way would be for it
to instead use hypercalls to retrieve the information.

Jan


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