Mailing List Archive

> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, Nov 05, 2004 at 11:28:25PM +0000, Ian Pratt wrote:
> It would be very cool ;-) We might even get distros to ship it on
> their install CD...

Exactly where I was going ... :)

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

Oh. Is there any way that the kernel can reuse that space
if it figures that it's not running under Xen. I haven't
looked too closely at the kernel's memory management, but
I seem to remember the zone allocators...

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

Yes, in which case we could maybe turn it *there* into a variable.

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

Maybe, but it would be bigger, and this maybe a problem for small
devices. Anyhow, not very satisfying :)

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

Yeah, I'd think this would be the preferable route. How large
would such a patch be?. It may be worth it to float it on LKML
to see the reaction :)

--
Dimi.


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, 5 Nov 2004, Ian Pratt wrote:

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

note that IBM did it with CMS under VM, see Melinda Varian's excellent
article on all this.

ron


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Ronald G. Minnich wrote:
> On Fri, 5 Nov 2004, Ian Pratt wrote:
>
>>>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".
>
> note that IBM did it with CMS under VM, see Melinda Varian's excellent
> article on all this.

<http://pucc.princeton.edu/~melinda/>
<http://pucc.princeton.edu/~melinda/25paper.pdf>

--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>



-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel