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