[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.3 release planning proposal

  • To: xen-devel@xxxxxxxxxxxxx
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Tue, 21 Aug 2012 07:50:53 -0700
  • Cc: george.dunlap@xxxxxxxxxxxxx
  • Delivery-date: Tue, 21 Aug 2012 14:51:22 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=m1ve2rzK5CxKg5v/6oW7kF10VpRdeR7iB4XpS9nIc2HW UK2b9zjZ8KjScIgoZqaSuVS4qXN5UFVA3ZCQsBiTeyXgYkBEelrKvWLtTFjl3/+7 0bh1393iwypkujM/NlKeBZ3uPJ7WLr38AJGRkWAzt5z8x01iaGig1cY7W3WJ/w4=
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

> Hello everyone!  With the completion of our first few release candidates
> for 4.2, it's time to look forward and start planning for the 4.3
> release.  I've volunteered to step up and help coordinate the release
> for this cycle.
Hi George. Great idea. Cutting to the chase below

An observation: the three below really sound like xapi or libvirt tasks.
> * Full-VM snapshotting
>   owner: ?
>   Have a way of coordinating the taking and restoring of VM memory and
>   disk snapshots.  This would involve some investigation into the best
>   way to accomplish this.
> * VM Cloning
>   owner: ?
>   Again, a way of coordinating the memory and disk aspects.  Research
>   into the best way to do this would probably go along with the
>   snapshotting feature.
> * Make storage migration possible
>   owner: ?
>   There needs to be a way, either via command-line or via some hooks,
>   that someone can build a "storage migration" feature on top of libxl
>   or xl.
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
This is one visible tip of the paging iceberg.

More generally, we need full wait-queue support for gfn translation
resolution. Working on this might include any of the folks who touched x86
mm code during 4.2.

Due to wait-queue locking limitations we decided not to tackle in the 4.2
time-frame, the hypervisor is unable to put a vcpu on a wait-queue in
hypervisor context at will. This means that right now, gfn->mfn
translations don't automagically hide all fixup conditions that require
helper intervention (paged out, unshare enomem). Fixing this will make the
p2m code a lot more self-contained and easier to parse, paging will be
completely transparent to guests (right now you can crash a guest with a
skillfully chosen paged out gfn), and will help you towards your goal of

> * Managed domains?

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.