On 12/10/16 12:06, Roger Pau Monne wrote:
> On Thu, Oct 06, 2016 at 09:20:07AM -0600, Jan Beulich wrote:
>>>>> On 27.09.16 at 17:57, <roger....@citrix.com> wrote:
>>> The logic used to setup the CPUID leaves is extremely simplistic (and
>>> probably wrong for hardware different than mine). I'm not sure what's the
>>> best way to deal with this, the code that currently sets the CPUID leaves
>>> for HVM guests lives in libxc, maybe moving it xen/common would be better?
>> Yeah, a pre-populated array of leaves certainly won't do.
> This is what current HVM guests use, and TBH, I would prefer to don't
> diverge from HVM. Would it make sense to leave this as-is, until all this
> cpuid stuff is fixed? (IIRC Andrew is still working on this).
My CPUID work will remove the need for any of this, (and indeed, is a
prerequisite for an HVM Control domain to build further HVM domains).
At boot, where we currently calculate the featuresets, we will also
calculate maximum full policies. domain_create() will clone the
appropriate default policy (pv or hvm) as a starting point.
A regular domU will have the toolstack optionally reduce the policy via
the domctl interface, but in the absence of any changes, the domain will
get the maximum supported featureset available on the hardware.
Xen-devel mailing list