All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	George Dunlap <George.Dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)
Date: Thu, 23 Jul 2015 10:08:46 +0100	[thread overview]
Message-ID: <1437642526.19412.54.camel@citrix.com> (raw)
In-Reply-To: <E1ZHxUW-0003iL-9o@ukmail1.uk.xensource.com>

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.

Boris and Roger will be the primary people working on this. Roger will
be looking at the no-dm loader side and then disabling Xen device
models, Boris will be looking at the Linux stub aspect.

There was talk about other things (e.g. VLAPIC using h/w support, UEFI
firmware) but those are future considerations.

Ian.


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

  reply	other threads:[~2015-07-23  9:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 17:07 [MINUTES] Monthly Xen.org Technical Call (2015-07-22) Ian Campbell
2015-07-23  9:08 ` Ian Campbell [this message]
2015-07-23  9:23   ` Roger Pau Monné
2015-07-23  9:35   ` Andrew Cooper
2015-07-23 10:10     ` Ian Campbell
2015-07-23 10:59   ` Konrad Rzeszutek Wilk
2015-07-23 11:17     ` Roger Pau Monné
2015-07-23 11:18       ` Andrew Cooper
2015-07-23 11:26       ` Ian Campbell
2015-07-23 17:44         ` Konrad Rzeszutek Wilk
2015-07-24  8:59           ` Ian Campbell
2015-07-23 17:42       ` Konrad Rzeszutek Wilk
2015-07-23 13:45   ` David Vrabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1437642526.19412.54.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Stefano.Stabellini@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=elena.ufimtseva@oracle.com \
    --cc=roger.pau@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.