[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




Mark Williamson <mark.williamson@xxxxxxxxxxxx> wrote on 08/04/2005 09:48:05 AM:

> 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.


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 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). 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.

>
> 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.

 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.