Xen devel - Apr 2006 - [PATCH][RFC] PNP Frontend/Backend: Legacy Devices in Driver Domains

The attached two patches add support to XenLinux to export devices
discovered through the Plug-n-Play subsystem to a driver domain. This
means that legacy devices discovered through ACPI (or possibly PNPBIOS
but I haven''t tested it) can be exported to driver domains similar to
how PCI devices are given to driver domains. Typical legacy devices
found in the ACPI tables are your serial and parallel ports (although
your motherboard manufacturer may have included all sorts of interesting
devices in your ACPI tables that can now be put in driver domains). This
new functionality *should* also allow TPMs (>= version 1.2) which appear
in the ACPI tables to be given to a driver domain (untested as of now).

This is accomplished through the creation of a PNP Backend and Frontend
pair. The PNP backend acts as a normal PNP driver registering itself
before all other PNP drivers (just like the PCI backend). This allows it
to be first in line to seize devices. By passing a Linux command-line
parameter (pnpback.hide), one can specify which PNP devices to "hide"
from the backend domain (Dom0). To give a PNP device to the frontend,
simply specify which device(s) in the domain''s configuration file. The
PNP frontend creates the appropriate PNP device structure in the driver
domain and registers it with the kernel.

I''m publishing these patches on the list as I''d like to get
some
feedback on them (although I wouldn''t mind if they are found acceptable
now and pulled into xen-unstable). Is this functionality of interest to
the Xen community? Do people have legacy devices that they''d like to
place in the frontend in a more plug-n-play manner over hard-coding the
IRQ and I/O ports in the configuration file? I know there have been
requests before for putting an external modem (serial port) in a driver
domain. This patch does it in a more automated way than the previous
method of hard-coding I/O resources in the domain''s configuration file
(it will also handle devices with I/O memory resources as there is
currently no option in the domain''s configuration file for specifying
those).

There''s a bit of overlap in these patches with the code in the PCI
backend, frontend, and the PCI tools and I''m considering some
possibilities to reduce this duplication (i.e. adding some kind of base
physical device code). If time permits, I hope to design, implement, and
submit a solution. But for now, I thought I''d put these out for
comment.

To use:

1) Apply the patches to xen-unstable (tested against changeset 9866)
2) Compile the PNP backend (listed under the Xen menu) and the PNP
frontend (listed under "Device Drivers"->"Plug and Play")
into your Xen
Linux kernel (while the backend should compile and run as a module, I
recommend you compile it in). You should also compile in (or as modules)
any drivers you need for your devices (like the 8250_pnp module for
serial ports).
3) Compile and install xen, XenLinux, and the xen tools.
4) Add a parameter (pnpback.hide) to your kernel command-line to specify
which devices to seize. Devices can be specified using EisaIDs or PNP
IDs. PNP IDs are Linux''s id numbers given to PNP devices. They can be
found in "/sys/bus/pnp/devices/". EisaIDs are specified by PNP
specifications and they indicate the class of hardware for a given
device. The distinction is important: Linux''s PNP IDs are unique to a
device while EisaIDs may apply to a group of devices. For example, 00:04
(a Linux PNP ID) may be the serial port in your system. Serial ports
have an EisaID of PNP0500 (or PNP0501). If you specify PNP0500, you will
grab all of your serial ports whereas specifying 00:04 will grab just
one. Your grub.conf file should contain lines like this:

title Xen PNP (kernel 2.6.16)
        root (hd0,3)
        kernel /xen.gz dom0_mem=262144
        module /vmlinuz-2.6.16-xen ro root=/dev/sda1 3
pnpback.hide=PNP0500,00:07
        module /initrd-2.6.16-xen.img

5) In your driver domain''s configuration file, add a
''pnp'' line
describing all of the devices to give away (specify by PNP ID). It''s
not
recommended, but you can specify devices by EisaID here also but note
that the EisaID won''t match all devices with that ID, just the first
one
it finds. For example:

kernel = "/boot/vmlinuz-2.6.16-xen"
extra = "ro 3"
memory = 128
name = "pnp_driver_domain"
disk = [''phy:your_domain_disk/drive,xvda1,w'']
root = "/dev/xvda1"
pnp = [''00:08'',''00:07'']

6) Start up your driver domain!


Here are some EisaIDs for common legacy devices:
PNP0500 - Serial Ports
PNP0501 - Newer Serial Ports
PNP0400 - Parallel Port
PNP0401 - ECP Parallel Port


There are some limitations of the PNP backend/frontend:
1) Legacy devices which need a DMA controller (i.e. your floppy disk
drive controller) can not be exported.
2) The data passed by the backend/frontend through XenStore is very
Linux-specific at the moment, a more abstract interface would be
desired.
3) Be aware that Xen currently allows overbooking of certain I/O
resources and it''s possible that a driver compiled into Dom0 and a
driver in your driver domain may try to use those resources
simultaneously.
4) No lazy binding (like the PCI backend driver)

Signed-off-by: Ryan Wilson <hap9@epoch.ncsc.mil>



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

On 27 Apr 2006, at 21:38, Ryan wrote:
> There''s a bit of overlap in these patches with the code in the PCI
> backend, frontend, and the PCI tools and I''m considering some
> possibilities to reduce this duplication (i.e. adding some kind of base
> physical device code). If time permits, I hope to design, implement, 
> and
> submit a solution. But for now, I thought I''d put these out for 
> comment.
Looks okay to me, but I''d be interested in hearing if anyone has a 
burning need for this driver before thinking about applying it. It 
would obviously be more attractive if it shared more code with the PCI 
codebase. Maybe the drivers could even be merged?

  -- Keir


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