Xen devel - Jul 2007 - Xen domU support merged into upstream Linux

I''m pleased to announce that Linus has just merged my Xen patches into
upstream git, so they will be released as part of 2.6.23.

The patches are 32-bit domU support, including:

    * netfront
    * blockfront
    * hvc console
    * SMP guests

Notable missing features at the moment are support ballooning and
suspend/migrate/resume, as well as dom0 and 64-bit support.  But
they''re
all on the TODO list.

And, as always, patches accepted ;)

    J


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

> I''m pleased to announce that Linus has just merged my Xen patches
into
> upstream git, so they will be released as part of 2.6.23.
Many congratulations Jeremy, that''s great news.  Huge props for taking
this
and making it really happen.  Hopefully it''ll be a real boost for Xen.
> The patches are 32-bit domU support, including:
>
>     * netfront
>     * blockfront
>     * hvc console
>     * SMP guests
That''s a nice range of functionality - all the really important core
things.
> Notable missing features at the moment are support ballooning and
> suspend/migrate/resume,
Out of interest, is there a particular issue with these, or is it just a case 
of concentrating on getting the core code in mainline first?
> as well as dom0 and 64-bit support.  But they''re 
> all on the TODO list.
I guess x86_64 is waiting on paravirt_ops stuff for that architecture, right?  
I guess dom0 support will probably have to be refactored somehow to be 
acceptable to mainline anyhow, but I presume we''ll need (something
like) more
paravirt_ops too, right?

Just curious as to what the future work would look like and where patches are 
likely to be focusing.
> And, as always, patches accepted ;)
Noted ;-)  I''ve got a git snapshot here to play with.  Are there any 
particular areas where you''re looking for patches?  e.g. things that
need
doing, but you don''t have time to look at immediately, or bits of 
infrastructure that need investigating?

Also, do you have any thoughts on Rusty''s virtio stuff?

Sorry for all the random questions, well done anyhow - great stuff.

Cheers,
Mark


-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

Mark Williamson wrote:
>>     * netfront
>>     * blockfront
>>     * hvc console
>>     * SMP guests
>>     
>
> That''s a nice range of functionality - all the really important
core things.
>
>   
>> Notable missing features at the moment are support ballooning and
>> suspend/migrate/resume,
>>     
>
> Out of interest, is there a particular issue with these, or is it just a
case
> of concentrating on getting the core code in mainline first?
>   
Mostly it was about getting a minimal useful set in early.  Originally
it was going to be UP only, but SMP turned out to be much easier than I
expected.

Suspend/resume interacts badly with preempt (which is supported).  I''ve
been trying to work out how to get them to play together, but I suspect
we''ll just need to make CONFIG_XEN_SUSPEND depend on !PREEMPT for now.

There are no particular problems with balloon, but it seems to me that
it could be dealt with a little better.  Maybe some combination of
memory hotplug+traditional ballooning.  Also, it became apparent at the
virtualization minisummit that balloon has a lot of common elements in
the various virtualization systems, and it might be worth making that
more universal - particularly the policy engine of distributing memory
across all the domain (I don''t know if this is a particular problem at
the moment, but it seems that s390 has some fairly reusable code we
might want to look at).
>> as well as dom0 and 64-bit support.  But they''re 
>> all on the TODO list.
>>     
>
> I guess x86_64 is waiting on paravirt_ops stuff for that architecture,
right?
>   
Yes, I''m looking at how that''s playing out, particularly since
Ingo and
Thomas Gleixner''s arch/x86 proposal the other day.
> I guess dom0 support will probably have to be refactored somehow to be 
> acceptable to mainline anyhow, but I presume we''ll need (something
like) more
> paravirt_ops too, right?
>   
Yes.  Well, maybe.  Unlike all the guest stuff, dom0 doesn''t really
have
any application beyond Xen.  I''m not sure whether we''ll come
up with
anything acceptible for mainline, but it depends on how things refactor
out.  I think a good initial goal is to come up with a reasonably clean
and maintainable out of tree patch set.
> Noted ;-)  I''ve got a git snapshot here to play with.  Are there
any
> particular areas where you''re looking for patches?  e.g. things
that need
> doing, but you don''t have time to look at immediately, or bits of 
> infrastructure that need investigating?
>   
In the short term I''m investigating dom0, since it has the most
unknowns
(at least for me).  64-bit will be an effort, but I don''t think there
are any deep problems which need to be solved there.  Most of the
existing code should be fairly 64-bit clean, and support for the 4th
pagetable level shouldn''t be too hard to add.  Almost all of the pv-ops
will still be used, simply because we still need to support 32-bit usermode.

There is the open question of whether we want to support pure pv 64-bit,
or if we should just go straight to a hybrid pv-hvm solution.  That is,
run the guest in an hvm container as ring0, use hvm to intercept a lot
of the boring operations, but keep using pv pagetables, etc.  How many
people are using pre-HVM 64-bit guests?
> Also, do you have any thoughts on Rusty''s virtio stuff?
>   
I think its an interesting idea.  If its possible to do a high
performance and featureful netfront driver with it, that''s cleaner than
the current code, then it will be worthwhile.  But I think that''s
definitely on the list of projects up for grabs.
> Sorry for all the random questions, well done anyhow - great stuff.
Thanks,
    J

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

Hi Jeremy,

First, congratulations for merging into 2.6.23.

On Tue, 2007-07-24 at 17:15 -0700, Jeremy Fitzhardinge
wrote:
> There is the open question of whether we want to support pure pv 64-bit,
> or if we should just go straight to a hybrid pv-hvm solution.  That is,
> run the guest in an hvm container as ring0, use hvm to intercept a lot
> of the boring operations, but keep using pv pagetables, etc.  How many
> people are using pre-HVM 64-bit guests?
> 
I tend to believe there are more pre-HVM 64-bit guests than 32-bit
guests. 64-bit CPUs are mainstream for a few years and 32-bit-only
server systems are getting old. Almost everyone I know with 64-bit CPUs
prefers to run 64-bit Linux over 32-bit.

So, I think it is worth to support pre-HVM 64-bit guests.


Cheers,

Jan



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

Jan Oravec wrote:
> I tend to believe there are more pre-HVM 64-bit guests than 32-bit
> guests. 64-bit CPUs are mainstream for a few years and 32-bit-only
> server systems are getting old. Almost everyone I know with 64-bit CPUs
> prefers to run 64-bit Linux over 32-bit.
>
> So, I think it is worth to support pre-HVM 64-bit guests.
Well, traditionally 64-bit guests have suffered a particularly steep
performance hit under Xen, so I suspect that a lot of people with 64-bit
hosts are still tending to use 32-bit guests.  But I''m just handwaving
really.

    J

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