Re: [PATCH] hvm/hpet: Alter hpet_init() to take a domain rather than vcpu

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

On 25/07/14 16:19, Jan Beulich wrote:
>>>> On 25.07.14 at 15:19, <andrew.cooper3@citrix.com> wrote:
>> There is nothing vcpu-specific about hpet_init(); all it does is follow the
>> vcpu's domain pointer to get at the domain vhpet state.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Jan Beulich <JBeulich@suse.com>
>>
>> ---
>>
>> Despite the comment in scope in hvm_vcpu_initialise(), the call can't
>> currently be moved to hvm_domain_initialise() as the extra hpet_deinit() (in
>> an error path) needs an allocated vcpu which wouldn't be present at that
>> point.  I need more tuits to disentangle that mess.
> And indeed I was about to ask that very question. Thanks for the
> patch in any case!
>
> Jan
>

I was wondering whether to extend the comment in the code, as it is not
very obvious that hpet_deinit(d) has an implicit requirement on
d->vcpu[0], but opted for the lazy route.

All of this is wrapped up in the pl_time which combines the vrtc, vhpet
and vpmt, where the vpmt has a hook onto vcpu[0], which all time pieces
share.

In an ideal world, I would expect there to be a vpmt per vcpu, and
vrtc/vhpet to hook onto the vioapic or vi8259 for the purpose of
delivering interrupts.  Part of the problem is that vcpu[0]'s guest time
is uses as a substitute for a domain wide time.

~Andrew