WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: AW: [Xen-devel] PCI bus emulation?

To: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: AW: [Xen-devel] PCI bus emulation?
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 4 Aug 2005 16:42:01 +0100
Cc: "Retzki, Sascha \[Xplain\]" <sascha.retzki@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 04 Aug 2005 19:52:38 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <OF507C4DC6.AAD19D9F-ON85257053.0054A171-86257053.005B0FA6@xxxxxxxxxx>
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: <OF507C4DC6.AAD19D9F-ON85257053.0054A171-86257053.005B0FA6@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.2
> It shuld be possible for domain 0 to read all devices from the bus and
> build its list. Then domain 0 could take the to-be-hidden devices out of
> that list

Yep.  Do you think it's possible to simply chop these devices out of the list 
after initialisation but before passing up to the generic PCI layer?  That'd 
be excellent.

> and maybe 'program' the virtualized PCI bus of a driver domain 
> to show these devices (through sending a message to the HV about what to
> present).

I'd be inclined to have this purely implemented at kernel level using 
interdomain comms, rather than having Xen know anything about it.

> A driver domain would still have to be co-operative in that 
> sense that it first starts out with a low privilege level (by default a
> domain would be created that way) to run into the exception handler and
> request to have its privilege level raised once it wants to access the raw
> hardware. Setting the individual privilege bits for a driver domain might 
> be another possibility, but you'd  need to know the list of ioports for
> each possible device.

Right now we do just that: domains never get access to the PCI controller, so 
config space accesses must always be mediated by Xen.  Domains are assigned 
direct access to the devices they control using IO port bits (although I'm 
not entirely happy with that, since it allows applications in the domain 
access to the device - fine for a driver domain but not good for partitioning 
the hardware) and controlled mapping of IO memory.

This works now because Xen can read the required IO port / memory ranges out 
of PCI config space and enable them as appropriate.  To make this work with 
the unstable tree, we'd need to have dom0's kernel somehow get this 
information out...

> > 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
>
> hardwaredirectly
>
> > and explicitly talks to dom0 e.g. using Xenstore to probe its devices.
>
> I also think that it would have the advantage of being able to build a
> user domain independently of whether it will become a driver domain or
> not. All the difference would be in the virtualized PCI bus presenting
> devices or being empty.

I definitely think we should retain the ability to build one kernel that works 
in all possible domains.  The startinfo does contain flags that tell the 
domain if it's dom0 (and therefore controls the PCI bus) or not.

Cheers,
Mark

>  Stefan
>
> > Cheers,
> > Mark
> >
> > > 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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