Re: [Xen-devel] Xen and Linux

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>]

> Hi folks,
> And congrats for the release of 2.0 -- this is really cool stuff.
> 
> While looking through Xen's features, I kept wondering if it's
> possible to have a common kernel binary that would work with/without
> Xen. In other words, to dynamically determine if it's running
> under Xen, and behave appropriately.

This has been dubbed "transparent virtualization". 

> And hence my questions:
>   -- is this possible to begin with?

yes, we believe so. It might be a bit gory though.

>   -- has anyone looked into it already?

We've thought about it, and even done a bit of reconnaissance.
Nobody is actively working on it, though.

>   -- what would be the implications?

It would be very cool ;-) We might even get distros to ship it on
their install CD...

>   -- any significant performance problems?

It depends on what granularity the switching is done, but I
believe it could be made to work fine. There needn't be much
run-time memory bloat as the unused functions could be thrown
away. 

There's one simple src change in arch Xen that has some quite far
reaching consequences: we change FIXADDR_TOP which effectively
gives us a 64MB whole at the top of the guest's VM space where
Xen lives. This constant gets compiled into a bunch of different
functions (though I believe it doesn't make it into modules
--phew!).

I suspect it would be unpopular to make FIXADDR_TOP a variable,
and it turns out to be a tricky thing to runtime patch. I think
we just have to have arch-xen specific versions of all of the
functions that use it. 

The simplest way to do this would be to have a tool that builds
an x86 and xen kernel then merges the two together. Sounds a bit
gross, but I think it would work quite well.

The alternative would be to make the changes at source level, but
this is actually more likely to marginally slow down normal
operation. 

2.6 has the beginnings of a boot-time switch mechanism to enable
support for different x86 instruction families. It would need to
be made quite a bit more extensive to cope with arch Xen.

Probably the cleanest solution of all would be to make all the
other architectures adopt Xen's nice clean interfaces and then
have stub routines for talking to the grotty realty of real
hardware. Might be a hard one to sell to Linus et al though ;-)

> Well, thank you for your time, and keep up the excellent work
> on this amazing project!

Cheers,
Ian


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel