WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen domU support merged into upstream Linux

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen domU support merged into upstream Linux
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 24 Jul 2007 17:15:41 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 24 Jul 2007 17:14:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200707241807.56329.mark.williamson@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <469E7103.3060209@xxxxxxxxxxxxx> <200707241807.56329.mark.williamson@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.5 (X11/20070719)
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>