Mailing List Archive

direct I/O access from domU
I want to make sure I am 'thinking about domU access to raw hardware correctly.

For our work we want to give Plan 9 domU direct access to a pci
device. This means that I/O, memory access is direct, IRQ goes to
domU, and so on. No intermediate access via dom0, and as little Xen
involvement as possible.

The way in which this is accomplished, from reading the docs and such
on the web, is not terribly clear to me.

I don't see any real use at present in pcifront. What would it do to
help that would not be done as well by direct access to 0xcf8/0xcfc?

For direct I/O mapping, some bits seem to be missing. I can ask for
the I/O range from domU, but there seem to be no tools that will let
me tell dom0 to allow a domU to have access to that range. From my
reading of source, some such tools are required. It would be much
better if I could specify the range in the /etc/xen/domU control file.
Do I need to write these tools?

Has anyone else out there tried this type of direct access to a device
from domU? I am also seeing problems with the pciback.hide etc. --
well, to put it simply, they don't seem to work at all.

If, for example, on Yenta, there is a driver loaded, the
/sys/bus/pci/devices/0000\:02\:00.0//driver symlink has a value. The
simple commands:
echo -n 0000:2:0.0>/sys/bus/pci/drivers/pciback/new_slot
echo -n bind 0000:2:0.0 > /sys/bus/pci/drivers/pciback/bind
have no effect on the value of this symlink. When I try to start the
domU, I get an error as the value of the symlink is not "pciback". It
seems I can not bind those devices if there is a driver loaded.

If there is no driver loaded for yenta, then the symlink has no value
and in fact does not exist. In this case, I get this error:
Error: pci: failed to locate device and parse it's resources - [Errno
2] No such file or directory:
'/sys/bus/pci/devices/0000:02:00.0/driver'

In no case is there an error from the 'echo' commands -- they don't do
what they're supposed to do, but they do fail very quietly :-)

So, the big question: I want to give a domU direct access to Yenta; I
want the I/Os and memory areas and DMA and IRQs and whatever going to
domU with (ideally) 0 involvement from dom0. How do I do this?

thanks
ron

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: direct I/O access from domU [ In reply to ]
On Wed, 2006-12-06 at 08:17 -0700, ron minnich wrote:
> Has anyone else out there tried this type of direct access to a device
> from domU? I am also seeing problems with the pciback.hide etc. --
> well, to put it simply, they don't seem to work at all.

I did this for my USB driver testing for the PCI USB h/w. I can't
remember the xen changeset which I used (it was xen 3 a few months ago)
but you could find out by searching the mailing list for the last time I
posted a USB split driver patch.

> So, the big question: I want to give a domU direct access to Yenta; I
> want the I/Os and memory areas and DMA and IRQs and whatever going to
> domU with (ideally) 0 involvement from dom0. How do I do this?

For the USB device it was fairly easy. Hide it from the dom0 kernel,
grant it to the domU kernel make sure pci back and front are compiled
into the dom0/domU kernels respectively.

Yenta is a PCI bridge though which rings alarm bells because the old
(Xen 2) driver domain support didn't work for bridges.

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: direct I/O access from domU [ In reply to ]
On 12/6/06, Harry Butterworth <harry@hebutterworth.freeserve.co.uk> wrote:

> I did this for my USB driver testing for the PCI USB h/w. I can't
> remember the xen changeset which I used (it was xen 3 a few months ago)
> but you could find out by searching the mailing list for the last time I
> posted a USB split driver patch.

Thanks. I wish I knew why hiding was not working for me.


> For the USB device it was fairly easy. Hide it from the dom0 kernel,
> grant it to the domU kernel make sure pci back and front are compiled
> into the dom0/domU kernels respectively.

ok, I need to write pcifront for Plan 9.
>
> Yenta is a PCI bridge though which rings alarm bells because the old
> (Xen 2) driver domain support didn't work for bridges.

ah. That might be it then. Anyone know for sure?

thanks

ron

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