Re: [Xen-devel] [PATCH v3 4/4] x86/PV: enable the emulated PIT

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.01.16 at 10:50, <roger.pau@xxxxxxxxxx> wrote:
> El 18/01/16 a les 8.43, Jan Beulich ha escrit:
>>>>> On 15.01.16 at 18:45, <roger.pau@xxxxxxxxxx> wrote:
>>> Changes since v2:
>>>  - Change 'if ( (a && b) || (!a && c) )' into 'if ( a ? b : c )'.
>> 
>> Thanks, but after some more thinking about it I'm afraid there are
>> a few more aspects to consider here:
>> 
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -542,8 +542,9 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
>>>                     d->domain_id, config->emulation_flags);
>>>              return -EINVAL;
>>>          }
>>> -        if ( config->emulation_flags != 0 &&
>>> -             (!is_hvm_domain(d) || config->emulation_flags != 
>>> XEN_X86_EMU_ALL) 
> )
>>> +        if ( is_hvm_domain(d) ? (config->emulation_flags != 
>>> XEN_X86_EMU_ALL &&
>>> +             config->emulation_flags != 0) :
>>> +             (config->emulation_flags != XEN_X86_EMU_PIT) )
>>>          {
>> 
>> For one I think it would be a good idea to allow zero for PV domains,
>> and perhaps even default new DomU-s to have the PIT flag clear.
>> (Also - indentation.)
> 
> This sounds fine to me, but IMHO, it should be done in a separate patch.
> This patch just restores previous behaviour for PV guests, then we can
> move on from there.

Well, maybe. To me it would seem cleaner if both options got
permitted by the code right away.

>> And then - is all this working as intended for the hwdom != Dom0
>> case?
> 
> I have to admit I have not tried it, but AFAICT in the hwdom != Dom0
> case the set of enabled emulated devices should be the same as a normal
> guest, the hardware domain doesn't get any more or less emulated devices
> than any other guest ATM.

No - see the use of is_hardware_domain() in pv_pit_handler().
IMO the flag should be forced on by the hypervisor for the
hardware domain, i.e. things be made independent of whatever
tooling gets used to create that domain.

Jan


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