Re: [Xen-devel] New Device Model?

[Daniel Stekloff <dsteklof@xxxxxxxxxx>]

On Wed, 2006-07-19 at 02:07 +0100, M.A. Williamson wrote:
> >There were some discussion about new device model for replacing the
> >QEMU.
> > 
> >Is there any roadmap for that? or working going on in that area which
> >can be pointed?
> 
> Intel was trying to implement live migrate (and suspend/resume) for HVM 
> guests a while back. A new version of ioemu is now in tree, using the 
> latest version of QEmu. For the forseeable future, it looks like Qemu will 
> be the basis for device emulation. There are plans to move the ioemu 
> functionality into paravirtualised stub domains, each serving one HVM 
> guest, but this hasn't happened yet (or indeed really begun AFAIK).


Yep, qemu will continue to do device emulation. We've started porting
the latest qemu to a paravirtualized "stub" domain, which will be
running a Linux domU kernel to start. Qemu will use front-end drivers in
the "stub" domain to perform IO like a normal paravirtualized domain. 

We've just started this work and we've got plenty of issues to
investigate:

1) What is the exact relationship between paravirtualized stub and HVM
domain? We will use a single domain structure and duplicate vpcu and
shared info to start. We'll probably start by duplicating more than we
have to and refining as we go.

2) How will we handle the needed privileged hypercalls in the "stub"
domain? We'll have domain0 run them on its behalf to start, making
"exceptions" for privileged calls doesn't sound like a good idea.

3) How much performance gain will there be - qemu will be running in
User Space in the "stub" domain to start? We should gain some advantage
since we won't have to switch out domains. Yet, I'm sure this'll be an
iterative process, having points where we need to investigate where we
can gain performance.

4) Qemu doesn't support the devices necessary - or we need better
emulation? New emulation will need to be added such as SCSI (which is in
the qemu tree), e1000, etc. 

Sorry we aren't further along.

Thanks,

Dan




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