Re: [Xen-devel] [PATCH 1/6] xen: use domid check in is_hardware_domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.03.14 at 16:25, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> On 03/05/2014 04:23 AM, Jan Beulich wrote:
>>>>> On 04.03.14 at 23:51, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -1505,7 +1505,7 @@ void context_switch(struct vcpu *prev, struct vcpu 
>>> *next)
>>>           }
>>>
>>>           set_cpuid_faulting(is_pv_vcpu(next) &&
>>> -                           (next->domain->domain_id != 0));
>>> +                           !is_control_domain(next->domain));
>>
>> I can't see why the hardware domain (which can't be migrated)
>> should be prevented from seeing the real CPUID values. It's
>> less obvious whether a control domain should always see real
>> values. Hence if you think the latter should be the case (as the
>> change above shows), I think you should check for both cases
>> here.
> 
> Agreed, the hardware domain also needs to be checked for here. The
> reason the control domain is present is that it needs to see real
> CPUID values in order to set CPUID policy for guests based on the
> real hardware values.

So don't envision a staged system where the root domain hides
some features from creation-capable ones, and those may hide
further features from their descendants? Up to where even the
controlling domains might become migratable?

> Using is_hardware_domain here avoids that problem (as the hardware domain
> may never shut down or be destroyed), so that may be the simplest
> solution until a better model of who is responsible for profiling is
> presented.

Then please do so, with a short note to that effect in either the
description or a code comment.

Jan


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