Re: [Xen-devel] (v2) VT-d Posted-interrupt (PI) design for XEN

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.03.15 at 09:49, <feng.wu@xxxxxxxxx> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Monday, March 23, 2015 4:26 PM
>> To: Wu, Feng
>> Cc: Tian, Kevin; Zhang, Yang Z; xen-devel@xxxxxxxxxxxxx; Keir Fraser
>> (keir@xxxxxxx)
>> Subject: RE: (v2) VT-d Posted-interrupt (PI) design for XEN
>> 
>> >>> On 23.03.15 at 09:14, <feng.wu@xxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Thursday, March 19, 2015 5:57 PM
>> >> >>> On 18.03.15 at 13:44, <feng.wu@xxxxxxxxx> wrote:
>> >> > Here are what we do for the blocked vCPU:
>> >> > 1. Define a per-cpu list 'blocked_vcpu_on_cpu', which stored the blocked
>> >> > vCPU on the pCPU.
>> >> > 2. When the vCPU's state is changed to RUNSTATE_blocked, 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.
>> >>
>> >> And this works transparently not only with the generic scheduler
>> >> code moving the vCPU to another pCPU, but also with some of the
>> >> individual scheduler implementations doing such re-assignments?
>> >
>> > I cannot quite understand this, could you please elaborate a bit more.
>> 
>> There are multiple places where v->processor can get changed for a
>> particular vCPU, and obviously all of these need to be taken care of.
>> Yet a change like the one to come here would normally not be
>> expected to touch specific schedulers' code, and hence suitably
>> abstracting this may need some extra thought.
> 
> Why do we need care about the places where v->processor gets changed,
> my idea about this is:
> 
> Before vCPU is blocked, we can get v->processor, and save the vCPU to
> this per-CPU list. Besides that v->processor is the destination of the 
> notification
> event (it is stored in Posted-interrupt descriptor). So when wakeup
> notification event happens form this vCPU, it goes to pCPU v->processor,
> then in the wakeup notification event handler, we can find the list via
> smp_processor_id(), hence find the right vCPU to wake up.
> 
> Do I miss something here?

Perhaps you don't, and perhaps I implied things I shouldn't have
implied: When v->processor changes, it would look to me that the
respective vCPU then ends up on the wrong list. If that's not a
problem - fine. Using per-CPU lists, however, would seem to make
it desirable to access those lists without lock, yet that can't work
when the list may get accessed from other than the owning CPU.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel