RE: [Xen-devel] RE: Rearchitecting IO Emulation for HVM Guests

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

Daniel Stekloff wrote:
> On Thu, 2006-06-08 at 13:02 -0700, Nakajima, Jun wrote:
>> We've been working on re-architecting the virtual device drivers
>> (such as netfront, blkfront) to minimize their Xen or Linux
>> dependencies so that we can load these drivers on broader ranges of
>> HVM guests. The new architecture has Xen and non-driver Linux code
>> in the stub domain. 
>> 
>> Our scope at this point is not the IO emulation as in qemu-dm, and I
>> believe our project and the one below will be complementary to each
>> other. 
>> 
>>> port xenbus/netfront/blkfront to minios
>> 
>> We've ported/moved part of the code above to minios (stub domain) to
>> make the cleaner netfront and blkfront drivers working, and the
>> prototype drivers have started working with the stub domain.
> 
> 
> Will the qemu io emulation that's planned for the stub domain use the
> stub domain's frontends to communicate with the backends in dom0?

I think that's a sensible design. The stub domain eventually needs to
talk to dom0 to read/write data, and we want to reuse the current
frontend and backend model. 

If you look at the current frontends in xenlinux, they are of course a
Linux driver. If you move them as they are to the stub domain, many
things are redundant when they work with the unmodified drivers in HVM
guests. For example, such drivers in HVM guests move data in buffers ->
the device (in the guest), then -> Linux data structure -> the Xen ring
buffer (in the stub domain). So what we need is to remove "-> Linux data
structure". 

> Is there a public tree that you're using? Or a public tree for this
> overall work, since adding changes to xen-unstable would be
> disruptive?

No, the tree requires cleanups for public consumption. At this point, we
are gathering data (not just performance) to convince ourselves that the
new architecture is the right one. 
 
> 
> Thanks,
> 
> Dan

Jun
---
Intel Open Source Technology Center

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