From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andres Lagar-Cavilla" Subject: Re: Xen 4.3 release planning proposal Date: Tue, 21 Aug 2012 07:50:53 -0700 Message-ID: References: Reply-To: andres@lagarcavilla.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org Cc: george.dunlap@eu.citrix.com List-Id: xen-devel@lists.xenproject.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 s/pod/paging/ Andres > > * Managed domains?