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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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