| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [Experimental PATCH] PCI and IO device emulation
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote on 09/28/2005 08:41:19 AM:
>
> On 28 Sep 2005, at 03:50, Stefan Berger wrote:
>
> > The attached patch is a continuation of my previous posts of
> > *experimental* patches where I tried to slide a PCI emulation layer
> > underneath dom-U. This now has no more changes to the PCI code in
> > Linux,
> > but does all the work in Xen. This patch now also adds IO port
> > emulation
> > of other ports than those related to PCI. Specifically it does the
> > following:
>
> I don't think this is the best approach, as it's a slippery slope. As
> you already note, domain0 doesn't know about hidden devices so it can't
> to interrupt routing and setup. Following this scheme, this would be
> extra platform code (potentially requiring a full ACPI interpreter)
> that would have to be added to Xen. That's a path we've already
> considered and decided not to take.
Would it help to make the system's ACPI data available to user domains (by
copying them into the user domain address space upon domain creation) so
they can do their own translations of IRQ numbers for those devices they
see?
>
> The only mechanism I think we should have in Xen is a protected
> interface for allowing domU's to access PCI config space. I would make
> it an explicit hypercall interface rather than bothering with emulating
> I/O port accesses -- we have to make modifications to the PCI stack
> anyway (otherwise we get into having to do crap like providing fake
> BIOS tables to provide dummy bus and irq info), and adding a new type
> of pci read/write access method is trivial in Linux. I expect the same
> is true of most other OSes.
I think the dummy bus could have a potential (double) benefit for running
unmodified legacy OSes as well and would not just serve 'driver domains'.
>
> This interface will reject all config accesses by default, but domain0
> can change access privileges on a per-device basis. All that Xen has to
> do is then mask off some of the registers for write access (e.g., don;t
> allow domU to arbitrarily rewrite resource base addresses) and possibly
> fake out reads for certain registers (e.g., perhaps the IRQ number
> register).
At least that part you could also solve by providing a PCI emulation
layer. Some devices can be accessible, others remain hidden. You can also
intercept requests to the IRQ number register and maybe return the
system's real IRQ number without having it translated in the user domain.
>
> All other smarts belong in domain0 imo. The only reason for not doing
> the whole lot in domain0 is that a pcifront/pciback split driver would
> be a lot more pain to write and to debug.
:-) I would push those smarts downwards to avoid changes in OS(es).
Stefan
>
> -- Keir
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home