| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: AW: [Xen-devel] PCI bus emulation?
[hiding PCI devices]
> A while back I had a look at this and it didn't look as if it would be very
> straight forward by just using arch specific code but probably doable using
> the hooks provided.
OK. I personally think we could (one day) argue its utility to the PCI core
but we probably don't want to try and merge changes to that upstream at the
same time.
> > > 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.
>
> I'm not entirely convinced that this is the right way to do. Once the
> devices are set up by dom0 xen wouldn't have to do that much and
> intercepting pci config read/writes in xen using the instruction emulator
> might be better and create less dependencies on Dom0.
How would config space writes work? Does Xen 3 understand enough about PCI to
implement those itself?
> The code in Xen 2.x dealing with PCI config reads/writes by device driver
> domains is actually quite small. Extending this to use the instruction
> decoder should be quite straight forward and less complex than doing a PCI
> config space frontend/backend type thing. And it would make changes to
> guests smaller than they already are in 2.x
I did wonder if the PCI back/front could be implemented entirely using
communications in the store - that could make them simpler. Requiring no
modifications to the read / write code would be a nice feature to have,
though.
Cheers,
Mark
> rolf
>
> > > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home