| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] pciback: deferred handling of pci configuration
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
|
|
|
| |
|
Home