|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|