Re: [XenARM] Questions on Xen Back end and front end drivers

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.

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