From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22) Date: Thu, 23 Jul 2015 10:35:40 +0100 Message-ID: <55B0B56C.4090302@citrix.com> References: <1437642526.19412.54.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZICup-0007eu-OA for xen-devel@lists.xenproject.org; Thu, 23 Jul 2015 09:35:47 +0000 In-Reply-To: <1437642526.19412.54.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , xen-devel@lists.xenproject.org Cc: Elena Ufimtseva , Wei Liu , George Dunlap , Stefano Stabellini , David Vrabel , Jan Beulich , Ian Jackson , Boris Ostrovsky , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On 23/07/15 10:08, Ian Campbell wrote: > On Wed, 2015-07-22 at 18:07 +0100, Ian Campbell wrote: >> This was the rescheduled 8 July call, on the topic of PVH and related >> work > CCing people who were on the call this time. > > Perhaps a summary of what we discussed/agreed (AIUI) would be easier to > (dis)agree with than the raw minutes: > > * Going forward we will switch to using the hvmlite/no-dm > approach to PV, rather than the existing "classic PVH" > approach. > * Any work which is specific to classic PVH may as well stop, but > anything which is common to both approaches could continue > * Boris' classic-PVH 32-bit domU support is basically > ready and there were no strong objections to putting it > in (after the 4.6 freeze, of course). > * The entry point shall be a flat 32-bit, paging disabled, entry > point (same as hvmloader today) > * Discovery of the Xen entrypoint will be via an ELF note > * For Linux: > * The Xen entrypoint shall point to a "stub" in > the same vein of the UEFI stub. > * The stub will set up a basic initial set of > page tables, fills in bootinfo and then jump to > the native 32- or 64-bit entry point as > appropriate. > * The stub can/should live in linux.git > (presumably arch/x86/xen) but should be self > -contained and isolated from the main body of > Linux code. It does setup to impedance match > the Xen entry point to the Linux native entry > point. > * Other things (e.g. lack of ACPI) should be > addressed by fixing the native Linux entry path > to be able to cope without them. Likewise > installing PV hooks may need hypervisor > detection to be moved earlier in the native > boot path. > * For BSD: > * I suppose Roger is on the case wrt agreeing > things with the BSD maintainers. I think model > is not dissimilar to that described for Linux. > * In Xen device models will be made optional and disabled. > * Secondary CPU bring up will be done using the PV paths > * Priority is to declare a stable API for basic domU use > excluding dom0, PCI passthrough and migration in the short > term. We are aiming to have this by ~January. I would not exclude migration from the basic domU use. Migration is a key feature of virtualisation, and being HVM-lite, means that the existing HVM migration path should JustWork. ~Andrew