Mailing List Archive

---- Resending in Plain message format  -----


Hi,

I read that DOM0 implements and handles all device drivers. All Domu's
access device driver through DOM0, For this back end and front end
drivers were created?. Just for understanding i was going  through Linux XEN Block back end and front end driver.(xen-blkfront.c), I am not sure but i see that there no real device involved in frontend and backend
communication? How does it boil down to Real device. What is the use of
XEN Block back end and front end drivers since there communication
happens only thru Memory ?.


For example i have a MTD Nand device which DOM0 should implement completely?.

How can other Domains access this MTD Device I guess we have to have a MTD
Back end driver for DOM0 and front end drivers for DOM U's?


My understanding is Back end drivers should do hardware specific tasks?.
Any good reference to understand backend and front end would be of great help.


Warm Regards,
Akshay

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

On Sun, 31 Mar 2013, akshay st wrote:
> ---- Resending in Plain message format  -----
>
>
> Hi,
>
> I read that DOM0 implements and handles all device drivers. All Domu's
> access device driver through DOM0, For this back end and front end
> drivers were created?. Just for understanding i was going  through Linux XEN Block back end and front end driver.(xen-blkfront.c), I am not sure but i see that there no real device involved in frontend and backend
> communication? How does it boil down to Real device. What is the use of
> XEN Block back end and front end drivers since there communication
> happens only thru Memory ?.

Communication between the frontend and the backend usually goes via a
ring buffer on a shared page. Notifications go through event channel
notifications, that are software interrupts provided by Xen.

The backend takes care of doing the real I/O on behalf of the guest,
using the appropriate internal Linux APIs (if the backend is in the
Linux kernel, it can also be in userspace).



> For example i have a MTD Nand device which DOM0 should implement completely?.
>
> How can other Domains access this MTD Device I guess we have to have a MTD
> Back end driver for DOM0 and front end drivers for DOM U's?

Assuming that mtdblock works with this device, then it should look like
a normal block device from blkback's point of view, so everything so
work as expected.
You can create partitions on the device and assign one or more of them
to one or more DomUs.


> My understanding is Back end drivers should do hardware specific tasks?.
> Any good reference to understand backend and front end would be of great help.

Backend drivers export a generic device of a specific kind to the guest:
a console, a video framebuffer, a network adapter, etc.
Even though at the moment we only ported the kernel backend drivers to
ARM (blkback and netback), few userspace backends exist in QEMU, and
they might help you get a better feeling of how they work.

For example, hw/xen_console.c in QEMU

http://git.qemu.org/?p=qemu.git;a=blob;f=hw/xen_console.c;h=a8db6f8d8f109d47e4a75314861ceedbe9ec6562;hb=HEAD

implements a PV console backend, the corresponding frontend is the
driver in Linux drivers/tty/hvc/hvc_xen.c.
Another block backend also exists in QEMU, it's called qdisk, see hw/xen_disk.c:

http://git.qemu.org/?p=qemu.git;a=blob;f=hw/xen_disk.c;h=83329e2e6906ffd14c59d99cc9fa14c207110514;hb=HEAD

A book describing the Xen architecture has been written few years ago:

The Definitive Guide to the Xen Hypervisor

it's now outdated but the part about PV frontends and backends should
still be relevant.

On Sun, 2013-03-31 at 12:47 +0100, akshay st wrote:
> Hi,
> I read that DOM0 implements and handles all device drivers. All Domu's
> access device driver through DOM0, For this back end and front end
> drivers were created?. Just for understanding i was going through
> Linux XEN Block back end and front end driver.(xen-blkfront.c), I am
> not sure but i see that there no real device involved in frontend and
> backend communication? How does it boil down to Real device.

For networking backend you would put the virtual device (the vif) and a
physical device on a standard Linux bridge, or you can use routing/nat
like you would in a non-virtualised router.

For disk backend the blkback driver opens the block device and forwards
requests.

> What is the use of XEN Block back end and front end drivers since
> there communication happens only thru Memory ?.
>
>
>
> For example i have a MTD Nand device which DOM0 should implement
> completely?.

There is currently no PV MTD device (unless the Xen PV ARM port contains
one, I've no idea).

You could potentially use mtdblock and blkback in the normal way, or you
could perhaps investigate passthrough, or maybe some higher level
service would be appropriate, it really depends what your use case is.

Ian.



_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm