WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [Experimental PATCH] PCI and IO device emulation


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.

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.

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

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.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel