Re: [Xen-devel] [RFC PATCH] dpci: Put the dpci back on the list if running on another CPU.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.01.15 at 02:44, <konrad.wilk@xxxxxxxxxx> wrote:
> Here is a patch that does this. I don't yet have an setup to test
> the failing scenario (working on that). I removed the part in
> the softirq because with this patch I cannot see a way it would
> ever get there (in the softirq hitting the BUG). 

Hmm, but how do you now schedule the second instance that needed ...

> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -64,16 +64,24 @@ static void raise_softirq_for(struct hvm_pirq_dpci 
> *pirq_dpci)
>  {
>      unsigned long flags;
>  
> -    if ( test_and_set_bit(STATE_SCHED, &pirq_dpci->state) )
> +    switch ( cmpxchg(&pirq_dpci->state, 0, 1 << STATE_SCHED) )
> +    {
> +    case (1 << STATE_SCHED):
> +    case (1 << STATE_RUN):

... in this case?

>> Additionally I think it should be considered whether the bitmap
>> approach of interpreting ->state is the right one, and we don't
>> instead want a clean 3-state (idle, sched, run) model.
> 
> Could you elaborate a bit more please? As in three different unsigned int
> (or bool_t) that set in what state we are in?

An enum { STATE_IDLE, STATE_SCHED, STATE_RUN }. Especially
if my comment above turns out to be wrong, you'd have no real
need for the SCHED and RUN flags to be set at the same time.

Jan


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