Xen devel - Dec 2005 - VT-X processors , xen 3.0 , drives and virtualization (in 32 bit environment)

Hello,

I had read about the new VT-x intel processors and Xen and I am
a bit confused.

According to Intel:
Intel(r) Virtualization Technology allows platforms to run
multiple operating systems and applications in independent partitions.
(I am not clear about what independent partitions exactly are).

In middle of November 2005 Intel anounced new processors
with Virtualization support:
I am talking about 672 and 662 processors with Intel Virtualization Technology
see for example :
http://www.linuxelectrons.com/article.php/20051114100516891


As far as I know,these processors would start shipping
early in Q1 of 2006 and they are still not availale widely (except
samples,tests,etc).
see:
http://lists.xensource.com/archives/html/xen-users/2005-12/msg00604.html

I have 2 questions:

 1) True to now and the current xen-3.0 version: When running Xen 3.0
 on these VT processors, can we run an unmodified kernel ?
 and in such a case, what about the device drivers - isn''t there a
 problem with them ? As I understand, the new VT extensions (of Intel)
 allow unmodified OS to run in different CPU contexts in
 a secured way : but sharing physical hw devices still
 requires adding sw support. Are there intentions from
 Xen project to add such hw drivers layer ? Or is it no problem at all??



I mean , in practical terms , if I will set my bootloader to have the
following entry on a machine with VT-x processor:
 kernel /xen.gz dom0_mem=x
 module /vmlinuz-#version ro root=...
 (and initrd if needed)
whereas vmlinuz-#version is an unmodified kernel of some distro:
will it work with support to block and net devices ? will I be
able to create a new domain based also on unmodified vmlinuz-#version
kernel ?

2) I tried to google for data about performance overhead of running
more than one Linux OS instance on these VT-processors but could not find
much.

Xen has an impressive low performance overhead when
using a patched kernel (about 3% of native).

Is there any official (or non-official) data on the performance of these
processors on VT-x processors ?

--IB

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

Ian Brown wrote:
>  1) True to now and the current xen-3.0 version: When running Xen 3.0
>  on these VT processors, can we run an unmodified kernel ?
For your DomUs, yes. For your Dom0, no. Running a modified DomU kernel 
should be more performant.
>  and in such a case, what about the device drivers - isn''t there a
>  problem with them ?
Emulated hardware, based off of drivers borrowed from QEMU, is provided 
to VMX domains. The drivers they need will be for the emulated cards, 
not for the real devices in the machine.
> I mean , in practical terms , if I will set my bootloader to have the
> following entry on a machine with VT-x processor:
>  kernel /xen.gz dom0_mem=x
>  module /vmlinuz-#version ro root=...
>  (and initrd if needed)
No, that won''t work, because that''s trying to use an
unmodified kernel
as Dom0.
> will I be
> able to create a new domain based also on unmodified vmlinuz-#version
> kernel ?
Yes, though VMX domains work a bit differently from non-VMX ones -- the 
process won''t be exactly the same except with a non-Xen-enabled kernel.


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

Hello,
  Ok, Thnks,this clears a lot about the first question.

Still, I will be grateful if I get any feedback on the second question
: performance overhead of running more than one Linux OS instance on
these VT-processors :
did anybody tried it and can comment on it / give some data / compare to
non VT processors
(which have aboutb 3% performance overhead) ? I would expect that
somebody had tried using these
VT chips (even they are still (maybe) in beta stage ).

Regards,
IB


On 12/27/05, Charles Duffy <cduffy@spamcop.net>
wrote:
> Ian Brown wrote:
> >  1) True to now and the current xen-3.0 version: When running Xen 3.0
> >  on these VT processors, can we run an unmodified kernel ?
>
> For your DomUs, yes. For your Dom0, no. Running a modified DomU kernel
> should be more performant.
>
> >  and in such a case, what about the device drivers - isn''t
there a
> >  problem with them ?
>
> Emulated hardware, based off of drivers borrowed from QEMU, is provided
> to VMX domains. The drivers they need will be for the emulated cards,
> not for the real devices in the machine.
>
> > I mean , in practical terms , if I will set my bootloader to have the
> > following entry on a machine with VT-x processor:
> >  kernel /xen.gz dom0_mem=x
> >  module /vmlinuz-#version ro root=...
> >  (and initrd if needed)
>
> No, that won''t work, because that''s trying to use an
unmodified kernel
> as Dom0.
>
> > will I be
> > able to create a new domain based also on unmodified vmlinuz-#version
> > kernel ?
>
> Yes, though VMX domains work a bit differently from non-VMX ones -- the
> process won''t be exactly the same except with a non-Xen-enabled
kernel.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Brown wrote:
>Hello,
>  Ok, Thnks,this clears a lot about the first question.
>
>Still, I will be grateful if I get any feedback on the second question
>: performance overhead of running more than one Linux OS instance on
>these VT-processors :
>did anybody tried it and can comment on it / give some data / compare to
>non VT processors
>(which have aboutb 3% performance overhead) ? I would expect that
>somebody had tried using these
>VT chips (even they are still (maybe) in beta stage ).
>  
>
VT support in Xen 3.0 is still mostly proof-of-concept.  It''s not
really
fair to use it to analyze the performance of VT since there hasn''t been
a lot (although there has been some) performance work done on VT.

The Xen VT support takes a pretty bad performance hit because of the 
fact that the device model is run in a different domain so there''s a 
pretty big hit from world/context switches.

Stay tuned though, because there''s no reason why future versions of Xen
shouldn''t perform quite well under VT :-)

Regards,

Anthony Liguori
>Regards,
>IB
>
>
>On 12/27/05, Charles Duffy <cduffy@spamcop.net> wrote:
>  
>
>>Ian Brown wrote:
>>    
>>
>>> 1) True to now and the current xen-3.0 version: When running Xen
3.0
>>> on these VT processors, can we run an unmodified kernel ?
>>>      
>>>
>>For your DomUs, yes. For your Dom0, no. Running a modified DomU kernel
>>should be more performant.
>>
>>    
>>
>>> and in such a case, what about the device drivers - isn''t
there a
>>> problem with them ?
>>>      
>>>
>>Emulated hardware, based off of drivers borrowed from QEMU, is provided
>>to VMX domains. The drivers they need will be for the emulated cards,
>>not for the real devices in the machine.
>>
>>    
>>
>>>I mean , in practical terms , if I will set my bootloader to have
the
>>>following entry on a machine with VT-x processor:
>>> kernel /xen.gz dom0_mem=x
>>> module /vmlinuz-#version ro root=...
>>> (and initrd if needed)
>>>      
>>>
>>No, that won''t work, because that''s trying to use an
unmodified kernel
>>as Dom0.
>>
>>    
>>
>>>will I be
>>>able to create a new domain based also on unmodified
vmlinuz-#version
>>>kernel ?
>>>      
>>>
>>Yes, though VMX domains work a bit differently from non-VMX ones -- the
>>process won''t be exactly the same except with a non-Xen-enabled
kernel.
>>
>>
>>_______________________________________________
>>Xen-devel mailing list
>>Xen-devel@lists.xensource.com
>>http://lists.xensource.com/xen-devel
>>
>>    
>>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

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