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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel