New Device Model?

New Device Model?

[Ahamed K, Rafiq (STSD)]

[-- Attachment #1.1: Type: text/plain, Size: 267 bytes --]

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?
 
Or do we have to use the paravirtualized drivers on fully virtualized
guests?
 
Best,
Rafiq

[-- Attachment #1.2: Type: text/html, Size: 1186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: New Device Model?

[M.A. Williamson]

>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).

>Or do we have to use the paravirtualized drivers on fully virtualized
>guests?

Those are also available (in development, anyhow) but the intent is to 
enhance the ioemu stuff too so that it has higher performance, supports 
migration, etc, etc.

Cheers,
mark

Re: New Device Model?

[Daniel Stekloff]

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

Re: New Device Model?

[Anthony Liguori]

On Tue, 18 Jul 2006 19:44:44 -0700, Daniel Stekloff wrote:
> 
> 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. 

You may want to look at the rtl8139 implementation in CVS (specifically,
the new C+ mode).  It supports TSO and checksum offloading.

May at least be worthwhile to evaluate which features from the e1000 are
desirable that the rtl8139 doesn't support (in C+ mode).

Regards,

Anthony Liguori

> Sorry we aren't further along.
> 
> Thanks,
> 
> Dan

Re: New Device Model?

[Mike D. Day]

Daniel Stekloff wrote:

> 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.

Are you talking about the dom0 hypercalls or others? domU hypercalls 
should be made by the stub domain on behalf of the fully virtualized 
dommain, right?

thanks in advance,

Mike