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

From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain
Date: Mon, 13 Mar 2017 05:48:44 -0600	[thread overview]
Message-ID: <58C6952C020000780014275A@prv-mh.provo.novell.com> (raw)
In-Reply-To: <36a14754-8a7e-854b-bad2-614f9eee3ca0@citrix.com>

>>> On 10.03.17 at 18:10, <andrew.cooper3@citrix.com> wrote:
> On 28/02/17 09:31, Jan Beulich wrote:
>>>>> On 27.02.17 at 16:10, <andrew.cooper3@citrix.com> wrote:
>>> On 22/02/17 10:10, Jan Beulich wrote:
>>>>>>> On 22.02.17 at 11:00, <andrew.cooper3@citrix.com> wrote:
>>>>> On 22/02/17 09:23, Jan Beulich wrote:
>>>>>>>>> On 20.02.17 at 12:00, <andrew.cooper3@citrix.com> 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 ...

Jan

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