[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 25/07/14 16:19, Jan Beulich wrote:
>>>> On 25.07.14 at 15:19, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxx>
>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>> ---
>> 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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.