Re: A couple of HVMlite loose ends

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 13/01/16 16:26, Jan Beulich wrote:
>>>> On 13.01.16 at 17:17, <andrew.cooper3@citrix.com> wrote:
>> On 13/01/16 16:13, Jan Beulich wrote:
>>>>>> On 13.01.16 at 16:49, <roger.pau@citrix.com> wrote:
>>>> Hello,
>>>>
>>>> While working on a HVMlite Dom0 implementation I've found a couple of
>>>> loose ends with the design that I would like to comment because it's not
>>>> clear to me what's the best direction to take.
>>>>
>>>> 1. HVM CPUID and Dom0.
>>>>
>>>> Sadly the way CPUID is handled inside of Xen varies between PV and HVM.
>>>> On PV guests AFAICT we mostly do black-listing (I think this is the
>>>> right term), which means we pick the native CPUID result and then
>>>> perform a series of filter operations in order to remove features which
>>>> should not be exposed to a PV guest. On the other hand, for HVM guests
>>>> we pre-populate an array (d->arch.cpuids) during domain build time, and
>>>> the contents of that array is what is returned to the guest when a CPUID
>>>> instruction is executed.
>>> This d->arch.cpuids[] mechanism is common to HVM and PV; the
>>> exception really is Dom0.
>> Dom0 is not special when it comes to cpuid, and shouldn't be treated as
>> such.  My longter term CPUID plans will be fixing this.
> In some way it is - there's no need for hiding features from it, since
> it can't be migrated.

Thats perfectly fine and normal.  The same applies to all other domains
which wont migrate, or will only migrate to identical hardware.

~Andrew