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] sharing PCI devices ....

To: "Himanshu Raj" <rhim@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] sharing PCI devices ....
From: "Petersson, Mats" <mats.petersson@xxxxxxx>
Date: Wed, 7 Sep 2005 15:48:50 +0200
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 07 Sep 2005 13:54:52 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWzsP2Myp0KnzY5Q/6XpnLVwPlGsQAAR4hA
Thread-topic: [Xen-devel] sharing PCI devices ....
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Himanshu Raj
> Sent: 07 September 2005 14:42
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] sharing PCI devices ....
> Hi Folks,
> A question about PCI devices. If we leave security problems 
> aside, is it possible to provide access of a PCI device to 2 
> domains (may include dom 0), i.e. would current xen 
> implementation suffice or a PCI device can only be used 
> exclusively by a domain.

If this is for an arbitrary device, it will not work. For a particular
device, assuming the device is REALLY TRIVIAL, it may be able to make it

Particularly, a device that uses interrupts to interact with the driver,
you would have a potential race condition between different drivers. 

There's also the case of conflicting settings/operations made by
different drivers and race-conditions.

Let's say a network card has a "start transmit bit" in one register, and
a "buffer-start" in a different register. Driver A in Dom0 writes a
value to Buffer start, gets interrupted [by timer or otherwise], DomU
writes to the buffer register as well, with a completely different
address, then writes sets the "start transmit bit". Once this is done,
it goes to sleep, and the schedueler decides to run the Dom0 again,
which writes the "start transmit bit". The card will then do one of:
<transmit the DomU packet again>, <report an error>, <fall over in a big
heap and fail to operate at all until next reboot>.

Of course, if there's no state, i.e. the card doesn't retain any
information from a single operation to the next, then it would probably
be possible to achieve a sharing. But I can't really think of any
(useful) card that works that way except for the "Port 80" cards that
show the status at boot, etc. 

A coordinated driver that has a shared [between host and guest]
mutex/spin-lock/semaphore/<insert other sycn mechanism(s) here> would
possibly work, but that's not what the current drivers are doing today,
so you'd need to construct such special driver for any hardware that you
want to share this way, and the complexity of this would possibly be
qutie huge. 

[I used to work for a graphics card company, writing drivers, and the
complexity of the driver in those are just HUGE, and the consequences of
a small change could very easily break the whole driver. Just the fact
that the system may switch from one task to another during a particular
driver call could often cause problems with coordinating the drivers and
hardwares state such the driver and hardware still knew what was going

> Thanks,
> Himanshu

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>