| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: AW: [Xen-devel] PCI bus emulation?
> -----Original Message-----
> From: Mark Williamson [mailto:mark.williamson@xxxxxxxxxxxx]
> Sent: 05 August 2005 01:11
> To: Neugebauer, Rolf
> Cc: Stefan Berger; Retzki, Sascha [Xplain]; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: 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?
If I remember correctly in 2.0 we don't allow writes to the config space bu
emulate them through very simple state machine. For normal linux guests the
only writes done through probing was the code which figured out the size of the
io memory regions, ie, read base, write all 1s, read again to find zeroed bits
and write back original base value (or something along those lines).
Obviously for this to work in Xen 3 xen would have to know a little about the
config space but once set up this should be relatively easy.
The other thing the backend/xen emulation would have to do is fake out some bus
"hierarchy" for device driver domains. Some of that code already exists in 2.x
> > 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.
It's a tradeoff and I think you can easily argue either way. I think the
crucial bit is the to find a clean solution for the dom0 issue. The config
space virtualization is probably reasonably straight forward either way.
rolf
> 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