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

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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [Experimental PATCH] PCI and IO device emulation
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Tue, 27 Sep 2005 22:50:29 -0400
Delivery-date: Wed, 28 Sep 2005 02:48:23 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hello!

 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:

- probes the PCI bus for devices and bridges etc. and makes all those 
devices that are not to be hidden available to domain 0; domain 0's in and 
out instructions are intercepted and those related to the PCI config 
spaces are 'passed through' to the real device
- allows to hide PCI devices from domain 0 and makes them available to the 
first user domain that starts up (hide=02:01.0 for example as parameter to 
the grub configuration line where xen.gz is passed); problem is still the 
interrupt for the device that does not reach the user domain
- opens the IO port ranges for the user domain according to the devices 
that it has been given to - I have added my own 64 k bits for port 
enablement for in/out instructions so there's duplication there right now 
with what has been done in Xen before; 
- places a mixture of fake and emulated PCI devices underneath user 
domains - domain 0 only sees real devices but like said before the 
commands are first intercepted and then passed through
- allows to hook emulation code for each IO port   (if a port is enabled, 
all in'out instruction are passed through, if it is disabled, a hander is 
search and if one is found it is invoked, otherwise a ~0 is returned)
- imports QEMU's PIC, PIT and RTC - I have fairly big confidence that 
these would be 'functionally ok', but most certainly not in terms of 
'timing' (RTC, PIT); the code changes in the related files were tried to 
be kept at a minimum; the 'loose' ends of PIC, PIT, and RTC are 'hooked 
up' to deliver interrupts and have the internal QEMU clock advanced  (see 
qemu_pc.c:pic_irq_request() for raising interrupts and xen/arch/x86/time.c 
'qemu_advance_clock()')
 - imports QEMU's APIC and IOAPIC - they don't work for sure due to some 
other missing hooks, but they compile fine

- code that needs to be looked at and improved is generally marked with 
'//!!!' 
- almost nothing is 'spinlocked'


One should be able to patch Xen with it and try it out. Everything should 
still work as it did before, unless one starts moving PCI devices to user 
domains. Let me know what you think.

Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>



Attachment: io_pci_emu_xen.diff
Description: Binary data

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