Re: [Xen-devel] [PATCH] pciback: deferred handling of pci configuration space accesses

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 25 Apr 2006, at 09:15, Keir Fraser wrote:

> >  Previously, the virtual configuration space handlers ran in
> > the same context as the event channel interrupt handler (which was 
> > often
> > atomic if not always atomic). Now the interrupt handler schedules a
> > callback function (a bottom half) in the system work queue (keventd)
> > that will get called in process context at a slightly later time. This
> > allows the handlers in the virtual configuration space to run in 
> > process
> > context and to call any core PCI function regardless of whether it 
> > will
> > sleep or not.
> This is okay in principle, but I found the op_in_progress counter 
> rather confusing and I'm not sure why it's needed? If it's to prevent 
> a double schedule_work() call on a single PCI request then I'm not 
> sure that it's watertight. Does it need to be?
Let me be a bit more specific here: I think that if an interrupt is 
delivered after the work function has incremented op_in_progress, but 
before it clears _PCIF_active, then work can be scheduled erroneously 
because the IRQ handler will see atomic_dec_and_test() return TRUE.
If serialised execution of pci requests is important, and it looks like 
it is, I think the simplest solution is simply to create your own 
single-threaded workqueue and queue_work() onto that. Personally I get 
worried about using the shared workqueues anyway, as they're another 
shared resource to deadlock on.
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel