From: Dave Young <dyoung@redhat.com>
To: Matt Fleming <matt@console-pimps.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>,
catalin.marinas@arm.com, will.deacon@arm.com,
matt.fleming@intel.com, ard.biesheuvel@linaro.org,
msalter@redhat.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org
Subject: Re: [PATCH 1/2] UEFI arm64: add noefi boot param
Date: Thu, 7 Aug 2014 09:27:09 +0800 [thread overview]
Message-ID: <20140807012708.GA20295@darkstar.nay.redhat.com> (raw)
In-Reply-To: <20140806140155.GC15082@console-pimps.org>
On 08/06/14 at 03:01pm, Matt Fleming wrote:
> On Wed, 06 Aug, at 02:29:41PM, Leif Lindholm wrote:
> > On Wed, Aug 06, 2014 at 02:20:21PM +0100, Matt Fleming wrote:
> > > > Since this is really turning an x86-specific feature into a generic
> > > > one, could it be moved to core code?
> > > > Maybe an efi.mask, reusing the efi_enabled defines, with an
> > > > efi_disabled macro?
> > >
> > > Why the new efi_disabled() and efi.mask? This is all achievable with
> > > efi_enabled() and efi.flags, in fact, this kind of thing is exactly why
> > > they were invented.
> >
> > Because this flag is indicating which facilities we should not try to
> > enable, rather than which facilities we have enabled.
> >
> > The EFI_RUNTIME_SERVICES flag is set after successful call to
> > set_virtual_address_map. The apparent intent of "noefi" is to prevent
> > that call from being made in the first place.
> >
> > Anyway, it was just a suggestion - main point was it would make sense
> > to share the code.
>
> Definitely.
>
> Dave, below is the kind of thing that I had in mind. Please Cc the Xen
> and SGI folks when you submit your next version because they're likely
> to be hit the hardest by any changes to EFI_RUNTIME_SERVICES and
> "noefi".
>
> Obviously the addition of "efi=noruntime" is needed on top, but that's
> about 6 lines of code.
[snip]
Matt, will file a new version based on your code. I will also address the
failure case in enter virtual mode.
Currently in x86, there's cases such as efi_map_regions failure and efi call
set_virtual_address_map, in case those failures it should be better to
unset the EFI_RUNTIME_SERVICES in efi.flags instead of do noting or panic.
As for Xen and SGI people? I have not been following all the efi threads
so I'm not sure who exactly I should cc, could you tell me?
Thanks
Dave
WARNING: multiple messages have this Message-ID (diff)
From: dyoung@redhat.com (Dave Young)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] UEFI arm64: add noefi boot param
Date: Thu, 7 Aug 2014 09:27:09 +0800 [thread overview]
Message-ID: <20140807012708.GA20295@darkstar.nay.redhat.com> (raw)
In-Reply-To: <20140806140155.GC15082@console-pimps.org>
On 08/06/14 at 03:01pm, Matt Fleming wrote:
> On Wed, 06 Aug, at 02:29:41PM, Leif Lindholm wrote:
> > On Wed, Aug 06, 2014 at 02:20:21PM +0100, Matt Fleming wrote:
> > > > Since this is really turning an x86-specific feature into a generic
> > > > one, could it be moved to core code?
> > > > Maybe an efi.mask, reusing the efi_enabled defines, with an
> > > > efi_disabled macro?
> > >
> > > Why the new efi_disabled() and efi.mask? This is all achievable with
> > > efi_enabled() and efi.flags, in fact, this kind of thing is exactly why
> > > they were invented.
> >
> > Because this flag is indicating which facilities we should not try to
> > enable, rather than which facilities we have enabled.
> >
> > The EFI_RUNTIME_SERVICES flag is set after successful call to
> > set_virtual_address_map. The apparent intent of "noefi" is to prevent
> > that call from being made in the first place.
> >
> > Anyway, it was just a suggestion - main point was it would make sense
> > to share the code.
>
> Definitely.
>
> Dave, below is the kind of thing that I had in mind. Please Cc the Xen
> and SGI folks when you submit your next version because they're likely
> to be hit the hardest by any changes to EFI_RUNTIME_SERVICES and
> "noefi".
>
> Obviously the addition of "efi=noruntime" is needed on top, but that's
> about 6 lines of code.
[snip]
Matt, will file a new version based on your code. I will also address the
failure case in enter virtual mode.
Currently in x86, there's cases such as efi_map_regions failure and efi call
set_virtual_address_map, in case those failures it should be better to
unset the EFI_RUNTIME_SERVICES in efi.flags instead of do noting or panic.
As for Xen and SGI people? I have not been following all the efi threads
so I'm not sure who exactly I should cc, could you tell me?
Thanks
Dave
next prev parent reply other threads:[~2014-08-07 1:27 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-06 8:38 [PATCH 1/2] UEFI arm64: add noefi boot param Dave Young
2014-08-06 8:38 ` Dave Young
2014-08-06 12:39 ` Will Deacon
2014-08-06 12:39 ` Will Deacon
2014-08-06 12:40 ` Ard Biesheuvel
2014-08-06 12:40 ` Ard Biesheuvel
2014-08-07 1:28 ` Dave Young
2014-08-07 1:28 ` Dave Young
2014-08-07 7:07 ` Ard Biesheuvel
2014-08-07 7:07 ` Ard Biesheuvel
[not found] ` <20140806083825.GA31711-je1gSBvt1Tc/CGXRbJeUwh/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2014-08-06 13:06 ` Leif Lindholm
2014-08-06 13:06 ` Leif Lindholm
2014-08-06 13:06 ` Leif Lindholm
2014-08-06 13:20 ` Matt Fleming
2014-08-06 13:20 ` Matt Fleming
[not found] ` <20140806132021.GB15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-06 13:29 ` Leif Lindholm
2014-08-06 13:29 ` Leif Lindholm
2014-08-06 13:29 ` Leif Lindholm
[not found] ` <20140806132941.GJ4179-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org>
2014-08-06 14:01 ` Matt Fleming
2014-08-06 14:01 ` Matt Fleming
2014-08-06 14:01 ` Matt Fleming
[not found] ` <20140806140155.GC15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-06 14:10 ` Ard Biesheuvel
2014-08-06 14:10 ` Ard Biesheuvel
2014-08-06 14:10 ` Ard Biesheuvel
[not found] ` <CAKv+Gu8ey1iKu-_wS6yYaEXQaQMDXa+PF5Kiw+edA9a_OE1EAw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-08-06 14:18 ` Matt Fleming
2014-08-06 14:18 ` Matt Fleming
2014-08-06 14:18 ` Matt Fleming
[not found] ` <20140806141814.GD15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-06 14:48 ` Leif Lindholm
2014-08-06 14:48 ` Leif Lindholm
2014-08-06 14:48 ` Leif Lindholm
[not found] ` <20140806144839.GK4179-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org>
2014-08-06 14:55 ` Matt Fleming
2014-08-06 14:55 ` Matt Fleming
2014-08-06 14:55 ` Matt Fleming
2014-08-07 6:19 ` Dave Young
2014-08-07 6:19 ` Dave Young
2014-08-07 6:19 ` Dave Young
[not found] ` <20140807061945.GE20295-4/PLUo9XfK+sDdueE5tM26fLeoKvNuZc@public.gmane.org>
2014-08-07 20:26 ` Matt Fleming
2014-08-07 20:26 ` Matt Fleming
2014-08-07 20:26 ` Matt Fleming
2014-08-11 9:00 ` Dave Young
2014-08-11 9:00 ` Dave Young
2014-08-07 1:27 ` Dave Young [this message]
2014-08-07 1:27 ` Dave Young
[not found] ` <20140807012708.GA20295-4/PLUo9XfK+sDdueE5tM26fLeoKvNuZc@public.gmane.org>
2014-08-07 20:09 ` Matt Fleming
2014-08-07 20:09 ` Matt Fleming
2014-08-07 20:09 ` Matt Fleming
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=20140807012708.GA20295@darkstar.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=leif.lindholm@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=matt@console-pimps.org \
--cc=msalter@redhat.com \
--cc=will.deacon@arm.com \
/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.