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: AW: [Xen-devel] PCI bus emulation?

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: AW: [Xen-devel] PCI bus emulation?
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 4 Aug 2005 15:48:05 +0100
Cc: "Retzki, Sascha \[Xplain\]" <sascha.retzki@xxxxxxxxx>, Stefan Berger <stefanb@xxxxxxxxxx>
Delivery-date: Thu, 04 Aug 2005 19:47:13 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <B1DC6EB706D5D511BC9F0050BA05FE10016024B2@xxxxxxxxxxxxxxxxxxxxxxxx>
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: <B1DC6EB706D5D511BC9F0050BA05FE10016024B2@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.2
Something similar to this is done already: domains are forced to access the 
PCI configuration spaces (which describes what cards are present and how 
they're configured) through hypercalls to Xen.  The hiding / revealing stuff 
just tells Xen what devices to let the domains see through this interface.

This is broken now because the PCI probing code has moved out of Xen, so dom0 
can always see all of the PCI devices and will grab them for itself.  What is 
needed is:
a) a way of dom0 initialising the bus but not grabbing all the devices
b) a way of allowing other domains to probe PCI config space via dom0 so it 
can control what devices they see

a) will require some tweaks to the PCI code in dom0.  b) will require some 
kind of virtualised PCI device (as Stefan described) that can control what 
the guest is allowed to see.

Using emulation to implement b) would have the advantage that the current 
probing code shouldn't need changing.  OTOH, the overall system may be 
simpler if the guest detects it's not allowed to access the hardware directly 
and explicitly talks to dom0 e.g. using Xenstore to probe its devices.


> I don't get the purpose. What is wrong with hiding certain PCI devices from
> DomO and thus make them available in domU?
> Btw, you are sure all OSes "find an empty bus"?
> -----Ursprüngliche Nachricht-----
> Von: Stefan Berger [mailto:stefanb@xxxxxxxxxx]
> Gesendet: Mittwoch, 3. August 2005 22:47
> An: xen-devel@xxxxxxxxxxxxxxxxxxx
> Betreff: [Xen-devel] PCI bus emulation?
> Hello!
>   I have seen that the Qemu code contains some nice code for PCI bus
> emulation. I wonder whether this code could be reused in XEN to fake a PCI
> bus by running the PCI emulation code in an exception handler in the
> hypervisor and setting a user domain's IO privilege level appropriately to
> have all inb/outb's intercepted. This could have potential benefits on the
> build process of user domains which could include the PCI code when built,
> but that code when probing the PCI bus would only find an empty bus and
> the probing of the drivers in the kernel would not start. Maybe this code
> could also be used to support driver domains. Is this a good idea? :-)
>   Stefan
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

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