All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Doug Goldstein <cardoe@cardoe.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Juergen Gross <JGross@suse.com>,
	sstabellini@kernel.org, konrad.wilk@oracle.com,
	pgnet.dev@gmail.com, ning.sun@intel.com, julien.grall@arm.com,
	qiaowei.ren@intel.com, xen-devel@lists.xen.org,
	gang.wei@intel.com, fu.wei@linaro.org
Subject: Re: [PATCH 0/4] multiboot2 protocol support
Date: Mon, 16 Jan 2017 04:56:57 -0700	[thread overview]
Message-ID: <587CC3190200007800130690@prv-mh.provo.novell.com> (raw)
In-Reply-To: <cover.d9ca2cf55d44ae792718e30d8086ef4f9315c8c7.1484335095.git-series.cardoe@cardoe.com>

>>> On 13.01.17 at 20:21, <cardoe@cardoe.com> wrote:
> This is a series based on v11 of Daniel Kiper's
> "x86: multiboot2 protocol support" series. It aims to collect up all the
> fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in
> code review and testing on actual hardware. I've had problems with the
> relocation portion of the series so I've dropped it as all the hardware I
> am needing to support presently for my $EMPLOYER does not load anything at
> the 1mb mark. To me this adds MB2 support for all pieces of hardware that
> don't have things located at 1mb so its an incremental step. I've also
> dropped the early command line conversion to C as it was done in support
> of the relocation changes and therefore not necessary. In the end my goal
> is to help Daniel out by providing the portion of the series that works
> on half a dozen physical machines I've tested with and integrates all
> changes as discussed on the v11 thread. The reason I am posting this is that
> Daniel has said he won't be able to address feedback and issues identified
> for another 2 weeks but my requirements from my $EMPLOYER are more immediate
> than that.
> 
> You can pull this series from https://github.com/cardoe/xen/tree/doug-mb2-v1 
> 
> Daniel Kiper (4):
>   x86: add multiboot2 protocol support
>   efi: build xen.gz with EFI code
>   efi: create new early memory allocator
>   x86: add multiboot2 protocol support for EFI platforms

Since this last patch continue to be controversial (and there's no
real point in committing the earlier three without the last one, as
only that one offers new functionality), so to be honest I'm not
sure this submission will accelerate anything. Iirc the main point
here is the not insignificant amount of new assembly code this
patch adds. Andrew - you've indicated you'd want to comment
on this and (of the original series) at least patch 11. When is
that going to happen?

Jan


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

  parent reply	other threads:[~2017-01-16 11:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-13 19:21 [PATCH 0/4] multiboot2 protocol support Doug Goldstein
2017-01-13 19:21 ` [PATCH 1/4] x86: add " Doug Goldstein
2017-01-13 19:21 ` [PATCH 2/4] efi: build xen.gz with EFI code Doug Goldstein
2017-01-13 19:21 ` [PATCH 3/4] efi: create new early memory allocator Doug Goldstein
2017-01-16 11:52   ` Jan Beulich
2017-01-16 13:55     ` Doug Goldstein
2017-01-13 19:21 ` [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms Doug Goldstein
2017-01-16 12:02   ` Jan Beulich
2017-01-16 12:50     ` Daniel Kiper
2017-01-16 13:41       ` Doug Goldstein
2017-01-16 14:11         ` Daniel Kiper
2017-01-16 14:28           ` Doug Goldstein
2017-01-16 15:16             ` Daniel Kiper
2017-01-17 12:05               ` George Dunlap
2017-01-17 12:45                 ` Daniel Kiper
2017-01-16 13:42     ` Doug Goldstein
2017-01-16 11:56 ` Jan Beulich [this message]
2017-01-18 17:38   ` [PATCH 0/4] multiboot2 protocol support George Dunlap
2017-01-19  8:31     ` Jan Beulich
2017-01-19 14:30       ` Doug Goldstein

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=587CC3190200007800130690@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=JGross@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=fu.wei@linaro.org \
    --cc=gang.wei@intel.com \
    --cc=julien.grall@arm.com \
    --cc=konrad.wilk@oracle.com \
    --cc=ning.sun@intel.com \
    --cc=pgnet.dev@gmail.com \
    --cc=qiaowei.ren@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xen.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.