This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ryan <hap9@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] pciback: deferred handling of pci configuration space accesses
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 25 Apr 2006 09:15:51 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 25 Apr 2006 01:16:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1145886765.7564.7.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1145886765.7564.7.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 24 Apr 2006, at 14:52, Ryan 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?

 -- Keir

Xen-devel mailing list