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-users] pv_ops dom0 kernel and VT cpu extensions

On Tue, Dec 29, 2009 at 11:29:27AM -0500, Gerry Reno wrote:
> Pasi Kärkkäinen wrote:
> >On Tue, Dec 29, 2009 at 11:24:17AM +0700, Fajar A. Nugraha wrote:
> >  
> >>On Tue, Dec 29, 2009 at 11:01 AM, Gerry Reno <greno@xxxxxxxxxxx> wrote:
> >>    
> >>>As physical boxes gain more and more processing capability it makes no 
> >>>sense
> >>>to restrict a physical machine to only a single hypervisor.
> >>>
> >>>Libvirt will support nested VM's that pass through the VT capabilities to
> >>>the next level.  So it makes sense that Xen should be able to do the same
> >>>thing and pass through the cpu VT capabilities to other hypervisors.  Is
> >>>there some law of the universe that prevents this?
> >>>      
> >>While KVM could probably do it, Xen currently can't. You might be able
> >>to get more answers about "why" and possible time line to support it
> >>(if any available) from xen-devel.
> >>
> >>    
> >
> >There was discussion about 'nested virtualization' with Xen at the
> >latest Xen Summit iirc.
> >
> >That still doesn't mean dom0 should have VT visible to it. in Xen world 
> >dom0 is just a PV (paravirtualized) virtual machine guest, 
> >so you can't run KVM in dom0. 
> >
> >If you want to run KVM under Xen HVM guest, then that should be
> >possible when 'nested virtualization' is supported in Xen.
> >
> >-- Pasi
> >  
> Thanks Pasi, that's interesting and I'll try it when it is available.  
> What would be best though is if Xen just passed the VT flags so that you 
> can run KVM in dom0.

There was also talks about converting dom0 to HVM guest instead of PV
guest; that might make it possible to run KVM in dom0.

Nested virtualization with Xen slides:

HVM dom0 slides:

-- Pasi

> As hardware continues to grow more powerful it won't be long before we 
> see as commonplace 64-core cpu, mult-terabytes of memory.  This will be 
> far more than any one hypervisor/kernel/os needs so we will need a way 
> to boot/run multiple hypervisors on bare-metal.  And that is why some 
> type of agnostic hypervisor-mediator-scheduler needs to run in Ring 0 
> and then all the hypervisors/kernels in Ring 1. 
> -Gerry

Xen-users mailing list