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/
Home Products Support Community News


Re: [Xen-devel] Question about VBD interface

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Question about VBD interface
From: "Mark A. Williamson" <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 4 Nov 2004 02:02:28 +0000
Cc: David Lie <lie@xxxxxxxxxxxxxxxx>
Delivery-date: Thu, 04 Nov 2004 03:42:59 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <loom.20041104T005724-556@xxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <loom.20041104T005724-556@xxxxxxxxxxxxxx>
Reply-to: mark.williamson@xxxxxxxxxxxx
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.6.2
For this e-mail, I'm assuming we're talking about Xen 2.0...

> I'm wondering how guest domains are provided access to disks.  I suppose
> Domain 0 has direct access to the actual hardware devices, and other
> domains simply see a virtualized block device.

All correct.

> However, when a guest 
> domain wants to make a request to the disk, how does it get that request to
> Domain 0 and how does Domain 0 actually receive those requests?

When it boots, the unpriv domain sets up sharing of a page of memory between 
its frontend driver and the backend driver running in domain 0.  The front 
and back end drivers do this by sending control messages via Xend.  Xend also 
binds an interdomain "event channel" between the two domains.  This allows 
the back and front end drivers to send each other "events" (virtual 

Once the shared memory page is set up and the event channel bound, the two are 
used for direct communication between the back and front end drivers.  Xend 
does not have to get involved anymore.

When the frontend wants to request data, it places a descriptor containng 
details of the request into the shared memory region.  It then sends an 
"event" to the backend driver (remember, this is running in dom0), which 
checks the shared memory region in response.

Assuming it decides the requests are valid, it will issue requests within the 
domain 0 kernel to perform the IO directly into the memory of the unpriv 
guest.  When the IO has finished, the backend puts a response into the shared 
memory page and sends an event to the frontend.  The frontend responds to the 
virtual interrupt by checking which IO completed and calling the appropriate 
completion handlers.

All this happens without Xen knowing about the virtual devices.  Xen operates 
at the level of shared memory and event channels - it doesn't know or care 
that domains are using these as virtual devices.

> There 
> appears to be a virtual block device driver in drivers/xen/blkfront &
> blkback.  Is this the driver used by the guest Domains to access the
> virtualized devices?

Correct again.

blkfront is the unpriv domain's part of the driver, blkback is the portion 
that runs in domain 0 and sends requests to the disk where appropriate.

Note that these are not pretending to be any specific model of real-world 
device - they're purely designed for high-performance virtual machine IO.

> My other question actually pertains to CoW support for disks.  I noticed
> that there was some work done on making a CoW driver that lived in the
> XenoLinux kernels.  Has this been made public?

Since device virtualisation moved into the dom0 kernel and out of Xen, it's 
possible to use your favourite CoW driver for vanilla Linux to achieve this.  
There's the LVM snapshot facility and, I think, the csnap driver and various 
other patches that are out there...

>  Have there been any
> attempts to make one that provides that functionality in Xen itself?

The functionality wouldn't be provided in Xen, since Xen itself doesn't manage 
devices (that's done by dom0 in Xen 2.0).  It wouldn't be a good idea to 
bloat the XenLinux backend driver with it anyway - the best idea is for a 
generic solution (like LVM, csnap, etc.).  Unfortunately LVM and csnap both 
have their drawbacks, which have previously been discussed on this list...


This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>