[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


 


Rackspace

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