Re: [Xen-devel] [PATCH v2] xen: use domid check in is_hardware_domain

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Jul 10, 2013 at 2:56 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 10.07.13 at 15:00, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
>> On Wed, Jul 10, 2013 at 12:43 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 10.07.13 at 12:57, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
>>>> On 09/07/13 21:28, Daniel De Graaf wrote:
>>>>> --- a/xen/arch/x86/domain.c
>>>>> +++ b/xen/arch/x86/domain.c
>>>>> @@ -1459,7 +1459,7 @@ void context_switch(struct vcpu *prev, struct vcpu
>> *next)
>>>>>           }
>>>>>
>>>>>           set_cpuid_faulting(!is_hvm_vcpu(next) &&
>>>>> -                           (next->domain->domain_id != 0));
>>>>> +                           !is_control_domain(next->domain));
>>>>
>>>> Won't this mean that in your separate hardware/control domain model that
>>>> the hardware domain *will* fault on cpuid? Is this what we want?
>>>
>>> I think this is correct, as it's the control domain that ought to be
>>> able to set up CPUID via the tool stack for all other domains.
>>>
>>> The implication is that it's the first booted domain. If that's not
>>> generally the case, we'd need another qualification here. And
>>> perhaps that qualification would in the end be domid == 0...
>>
>> The question isn't why the control domain has it; the question is why
>> the hardware domain doesn't have it.
>
> Because - as said - for _all_ other domains, the control domain can
> set a CPUID policy via the tool stack.

So you're saying that the control domain will set the CPUID policy for
the hardware domain?

>
>>>>> @@ -1962,7 +1962,7 @@ static void dump_softtsc(unsigned char key)
>>>>>                  "warp=%lu (count=%lu)\n", tsc_max_warp, tsc_check_count);
>>>>>       for_each_domain ( d )
>>>>>       {
>>>>> -        if ( d->domain_id == 0 && d->arch.tsc_mode == TSC_MODE_DEFAULT )
>>>>> +        if ( is_hardware_domain(d) && d->arch.tsc_mode == 
>>>>> TSC_MODE_DEFAULT )
>>>>>               continue;
>>>>>           printk("dom%u%s: mode=%d",d->domain_id,
>>>>>                   is_hvm_domain(d) ? "(hvm)" : "", d->arch.tsc_mode);
>>>>
>>>> Why have direct access to the tsc for the hardware domain and not the
>>>> control domain?
>>>
>>> Because, as its name says, it has direct access to the hardware
>>> (including the TSC)?
>>
>> Again, my question wasn't so much about why the hardware domain does
>> have it, but why the control domain does *not* have it.
>
> And I think I answered it. Or should I return the question and ask:
> "Why do you think the control domain should be using the TSC
> directly? I.e. in what way is it different from other non-hardware
> domains in its interaction with hardware?"

Well why does the hardware domain, or even domain 0, need it?  "It has
direct access to the hardware" isn't really an answer.

 -George

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