[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 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |