From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Ian Campbell <ian.campbell@citrix.com>
Cc: elena.ufimtseva@oracle.com, wei.liu2@citrix.com,
andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
xen-devel@lists.xenproject.org,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
Date: Tue, 23 Jun 2015 22:45:14 -0400 [thread overview]
Message-ID: <558A19BA.4070400@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1506231412070.4824@kaball.uk.xensource.com>
On 06/23/2015 09:12 AM, Stefano Stabellini wrote:
> On Tue, 23 Jun 2015, Ian Campbell wrote:
>> On Tue, 2015-06-23 at 11:55 +0100, Stefano Stabellini wrote:
>>> I don't know if we should introduce a new name for this, but I wanted to
>>> point out that this is different from PVH from Xen point of view. In
>>> particular most of the outstanding PVH work items (32bit, AMD) on the
>>> hypervisor would be redudant if we get this to work, right? If that is
>>> the case, then I think it is best we agree on which road we want to take
>>> going forward as soon as possible to avoid duplicated or wasted efforts.
>> I think what you are saying is we either want to pursue this path _or_
>> PVH, but not both, and I would be inclined to agree, it seems to me like
>> duplication of both effort and functionality to do both.
> Right, especially given that they both seem to provide similar
> functionalities.
Given that 32-bit support of existing PVH model looks pretty simple and
required AMD changes are also well understood (right?) and do not appear
particularly invasive I would argue for finishing those two while
continuing to work on unified boot model.
-boris
next prev parent reply other threads:[~2015-06-24 2:45 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 16:11 [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI Roger Pau Monne
2015-06-22 16:11 ` [PATCH RFC v1 01/13] libxc: split x86 HVM setup_guest into smaller logical functions Roger Pau Monne
2015-06-22 16:11 ` [PATCH RFC v1 02/13] libxc: unify xc_dom_p2m_{host/guest} Roger Pau Monne
2015-06-22 16:11 ` [PATCH RFC v1 03/13] libxc: introduce the notion of a container type Roger Pau Monne
2015-06-22 16:11 ` [PATCH RFC v1 04/13] libxc: allow arch_setup_meminit to populate HVM domain memory Roger Pau Monne
2015-06-25 10:29 ` Wei Liu
2015-06-25 10:33 ` Wei Liu
2015-06-22 16:11 ` [PATCH RFC v1 05/13] libxc: introduce a domain loader for HVM guest firmware Roger Pau Monne
2015-06-23 9:29 ` Jan Beulich
2015-06-23 9:36 ` Roger Pau Monné
2015-07-10 19:09 ` Konrad Rzeszutek Wilk
2015-06-22 16:11 ` [PATCH RFC v1 06/13] libxc: introduce a xc_dom_arch for hvm-3.0-x86_32 guests Roger Pau Monne
2015-06-22 16:11 ` [PATCH RFC v1 07/13] libxl: switch HVM domain building to use xc_dom_* helpers Roger Pau Monne
2015-06-22 16:11 ` [PATCH RFC v1 08/13] libxc: remove dead x86 HVM code Roger Pau Monne
2015-06-22 16:11 ` [PATCH RFC v1 09/13] elfnotes: intorduce a new PHYS_ENTRY elfnote Roger Pau Monne
2015-06-23 9:35 ` Jan Beulich
2015-06-23 9:40 ` Roger Pau Monné
2015-06-23 10:01 ` Jan Beulich
2015-06-22 16:11 ` [PATCH RFC v1 10/13] lib{xc/xl}: allow the creation of HVM domains with a kernel Roger Pau Monne
2015-06-25 10:39 ` Wei Liu
2015-06-22 16:11 ` [PATCH RFC v1 11/13] xen/libxl: allow creating HVM guests without a device model Roger Pau Monne
2015-06-23 9:41 ` Jan Beulich
2015-06-22 16:11 ` [PATCH RFC v1 12/13] xen: allow 64bit HVM guests to use XENMEM_memory_map Roger Pau Monne
2015-06-23 9:43 ` Jan Beulich
2015-06-22 16:11 ` [PATCH RFC v1 13/13] xenconsole: try to attach to PV console if HVM fails Roger Pau Monne
2015-06-22 17:55 ` [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI Stefano Stabellini
2015-06-22 18:05 ` Konrad Rzeszutek Wilk
2015-06-23 8:14 ` Roger Pau Monné
2015-06-23 10:55 ` Stefano Stabellini
2015-06-23 12:50 ` Ian Campbell
2015-06-23 13:12 ` Stefano Stabellini
2015-06-24 2:45 ` Boris Ostrovsky [this message]
2015-06-24 9:47 ` Roger Pau Monné
2015-06-24 10:05 ` Jan Beulich
2015-06-24 10:14 ` Roger Pau Monné
2015-06-24 11:52 ` Boris Ostrovsky
2015-06-24 12:04 ` Roger Pau Monné
2015-06-24 13:36 ` Konrad Rzeszutek Wilk
2015-07-03 16:22 ` Tim Deegan
2015-06-24 13:26 ` Stefano Stabellini
2015-06-24 16:30 ` Boris Ostrovsky
2015-06-24 17:54 ` Stefano Stabellini
2015-06-23 7:14 ` Roger Pau Monné
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=558A19BA.4070400@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=elena.ufimtseva@oracle.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=roger.pau@citrix.com \
--cc=stefano.stabellini@eu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).