-
> arch/x86/include/asm/io.h |5 +
> arch/x86/mm/ioremap.c | 179
> +
> include/linux/io.h|2 +
> kernel/memremap.c | 20 -
> mm/early_ioremap.c| 18 -
> 5 files
ov <b...@suse.de>
> Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com>
> ---
> arch/x86/platform/efi/efi_64.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>
> drivers/firmware/efi/efi.c | 33 +
> include/linux/efi.h|7 +++
> 2 files changed, 40 insertions(+)
Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>
___
Xen-devel mailing list
Xen-
l/efi.c |4 ++--
> arch/x86/platform/efi/efi.c |6 +++---
> include/linux/efi.h |2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote:
> On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote:
> > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
> > >
> > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper,
> > &
On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
>
> Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper,
> rather than spreading it further.
>
> IMO, given reset_system is a *mandatory* function, the Xen wrapper
> should provide an implementation.
>
> I don't see why you
On Wed, 18 May, at 12:46:38PM, Ingo Molnar wrote:
>
> I have no particular objections, since this seems to be Xen-next merged to
> the EFI
> tree that is already upstream, plus this single commit on top of t:
>
> 11ee5491e5ff Xen: EFI: Parse DT parameters for Xen specific UEFI
>
> Which, if
copy batch size to 16
Matt Fleming (1):
Merge branch 'xen/linux-next' into efi/arm-xen
Shannon Zhao (16):
Xen: ACPI: Hide UART used by Xen
xen/grant-table: Move xlated_setup_gnttab_pages to common place
Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
ar
calls and they are always enabled. So it
> sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and
> bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES
> flag is set already.
>
> CC: Matt Fleming <m...@codeblueprint.co.uk>
> Signed-off-by:
On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote:
>
> As said above, I will rebase this patch on top of the EFI next branch.
OK thanks.
Note that it is not possible to escape merge conflicts, since there
are changes in the xen tip tree that are not in the EFI next branch
and vice versa.
For
On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote:
> >
> > Also, why do you need to setup efi.runtime_version here? Isn't that
> > done inside uefi_init()?
> >
> I don't see any codes which setup efi.runtime_version in uefi_init().
Look in the EFI tree,
On Fri, 06 May, at 09:52:42AM, Mathieu Poirier wrote:
> > +static int __init efi_remap_init(void)
> > +{
> > + u64 mapsize;
> > +
> > + pr_info("Remapping and enabling EFI services.\n");
> > +
> > + mapsize = memmap.map_end - memmap.map;
> > + memmap.map = (__force void
from bare metal?
- Why is it OK to force enable EFI runtime services for Xen?
I think it would also be good to explicitly state that we do not
expect to find both Xen EFI DT parameters and bare metal EFI DT
parameters when performing the search; the two should be mutually
exclusive
On Tue, 03 May, at 09:45:22AM, Shannon Zhao wrote:
> > +static int __init fdt_find_uefi_params(unsigned long node, const char
> > *uname,
> > + int depth, void *data)
> > +{
> > + struct param_info *info = data;
> > + int i;
> > +
> > + for (i = 0; i <
On Sun, 01 May, at 10:36:51PM, Shannon Zhao wrote:
> So is there any other way you suggest?
Would this work (compile tested but not runtime tested)?
---
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3a69ed5ecfcb..13d8be16447a 100644
--- a/drivers/firmware/efi/efi.c
On Sun, 01 May, at 11:24:18AM, Shannon Zhao wrote:
> Because the UEFI params for Dom0 are located under /hypervisor/uefi node
> instead of /chosen. So it needs to check whether it's a Dom0 then search
> and parse different node with different params arrays.
Why can't you search both nodes? Would
On Sat, 30 Apr, at 10:14:42PM, Shannon Zhao wrote:
> Sure. How should I add this change? Rework this patch or add new one on
> top of it?
Rework this patch, please.
> Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in
> fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and
On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > Also, it would be nice to have all things EFI in a single tree, the
> > conflicts are
> > going to be painful! There's very little reason not to carry this kind of
> > commit:
> >
> >
On Fri, 29 Apr, at 10:25:02AM, Borislav Petkov wrote:
> On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote:
> > With considerable pain we just got rid of paravirt_enabled() in the
> > x86 tree, and Xen is now reintroducing it in the EFI code.
>
> I think Matt is working towards removing
(Sorry, just realised I never replied to this)
On Wed, 13 Apr, at 01:59:10PM, Roger Pau Monné wrote:
>
> Is this header compatible with the ELF header? Con both co-exist in the
> same binary without issues?
Nope, they cannot. We get away with mixing bzImage headers and PE/COFF
headers for the
On Wed, 13 Apr, at 11:15:15AM, Matt Fleming wrote:
>
> For 1. we'd basically be using the PE/COFF file format with the EFI
> ABI as an OS agnostic boot protocol, but not as a full firmware
> runtime environment.
To add some balance to this proposal (since there's no such thing as
On Wed, 13 Apr, at 12:03:12PM, Roger Pau Monné wrote:
>
> I don't get this, the "reset/shutdown" hypercall requires the following
> steps from Dom0 (it's not as simple as calling a hypercall):
>
> The way to perform a full system power off from Dom0 is different than
> what's done in a DomU
On Wed, 13 Apr, at 11:02:02AM, Roger Pau Monné wrote:
>
> With my FreeBSD committer hat:
>
> The FreeBSD kernel doesn't contain an EFI entry point, it just contains one
> single entry point that's used for both legacy BIOS and EFI. Then the
> FreeBSD loader is the one that contains the
On Wed, 06 Apr, at 12:07:36PM, George Dunlap wrote:
>
> So rather than make a new entry point which does just the minimal
> amount of work to run on a software interface (Xen), you want to take
> an interface designed for hardware (EFI) and put in hacks so that it
> knows that sometimes some EFI
tialize runtime services.
>
> Signed-off-by: Shannon Zhao <shannon.z...@linaro.org>
> ---
> CC: Matt Fleming <m...@codeblueprint.co.uk>
> ---
> arch/arm/xen/enlighten.c | 6 ++
> arch/arm64/kernel/efi.c| 17 -
> drivers/firmware/efi/e
25 matches
Mail list logo
