[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design
> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx] > Sent: Tuesday, November 10, 2015 10:52 PM > > > > +Here are what we do for the blocked vCPU: > > +1. Define a per-cpu list 'pi_blocked_vcpu', which stored the blocked > > +vCPU on the pCPU. > > +2. When the vCPU is going to block, insert the vCPU > > +to the per-cpu list belonging to the pCPU it was running. > > +3. When the vCPU is unblocked, remove the vCPU from the related pCPU > > list. > > + > > +In the handler of 'pi_wakeup_vector', we do: > > +1. Get the physical CPU. > > +2. Iterate the list 'pi_blocked_vcpu' of the current pCPU, if 'ON' > > is set, > > +we unblock the associated vCPU. > > + > This is indeed more general, and the fact that it does no longer > mentions RUNSTATEs, makes it more adherent to the actual implementation > (and hence more useful), so thanks for doing this. > > Personally, I'd add a quick comment about how this, despite being > related to blocking and unblocking, happens actually inside VMX > handlers, i.e., (quickly) what is the relationship within these sets of > events (blocking/unblocking VMENTER/EXIT) and why it is ok to do things > like they are done. > > I'm not too fussed about this, though. So, if others don't think > something like this is necessary, I'm fine with what you have here. > That type of information is welcomed. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |