Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

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 <

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

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 <

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

On 2016/4/30 22:14, Shannon Zhao wrote: >> I already proposed when this patch was first under review to make the >> > arm_enable_runtime_services() function bail early without error if the >> > EFI_RUNTIME_SERVICES flag is already set, and the xen code could set >> > that bit as well when it

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

On 2016/4/30 22:14, Shannon Zhao wrote: >> I already proposed when this patch was first under review to make the >> > arm_enable_runtime_services() function bail early without error if the >> > EFI_RUNTIME_SERVICES flag is already set, and the xen code could set >> > that bit as well when it

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

On 2016/5/2 18:45, Matt Fleming wrote: > 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

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

On 2016/5/2 18:45, Matt Fleming wrote: > 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

Re: efi_enabled(EFI_PARAVIRT) use

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

Re: efi_enabled(EFI_PARAVIRT) use

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

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年05月01日 21:26, Matt Fleming wrote: > 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

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年05月01日 21:26, Matt Fleming wrote: > 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

Re: efi_enabled(EFI_PARAVIRT) use

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

Re: efi_enabled(EFI_PARAVIRT) use

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

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年05月01日 04:44, Matt Fleming wrote: >> While I still have a question, in this patch we use >> > efi_enabled(EFI_PARAVIRT) as a condition to make fdt_find_uefi_params() >> > and efi_get_fdt_params() execute different ways. So it needs to find a >> > new condition for that if we need to get

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年05月01日 04:44, Matt Fleming wrote: >> While I still have a question, in this patch we use >> > efi_enabled(EFI_PARAVIRT) as a condition to make fdt_find_uefi_params() >> > and efi_get_fdt_params() execute different ways. So it needs to find a >> > new condition for that if we need to get

Re: efi_enabled(EFI_PARAVIRT) use

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

Re: efi_enabled(EFI_PARAVIRT) use

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

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年04月29日 22:53, Ard Biesheuvel wrote: > On 29 April 2016 at 16:39, Matt Fleming wrote: >> 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

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年04月29日 22:53, Ard Biesheuvel wrote: > On 29 April 2016 at 16:39, Matt Fleming wrote: >> 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

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年04月29日 23:37, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Stefano Stabellini wrote: >> On Fri, 29 Apr 2016, Matt Fleming wrote: >>> 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

Re: efi_enabled(EFI_PARAVIRT) use

On 2016年04月29日 23:37, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Stefano Stabellini wrote: >> On Fri, 29 Apr 2016, Matt Fleming wrote: >>> 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

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr 2016, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Matt Fleming wrote: > > 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 >

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr 2016, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Matt Fleming wrote: > > 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 >

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr 2016, Matt Fleming wrote: > 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

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr 2016, Matt Fleming wrote: > 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

Re: efi_enabled(EFI_PARAVIRT) use

On 29 April 2016 at 16:39, Matt Fleming wrote: > 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!

Re: efi_enabled(EFI_PARAVIRT) use

On 29 April 2016 at 16:39, Matt Fleming wrote: > 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

Re: efi_enabled(EFI_PARAVIRT) use

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: > > > >

Re: efi_enabled(EFI_PARAVIRT) use

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: > > > >

Re: efi_enabled(EFI_PARAVIRT) use

* 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: > > > >

Re: efi_enabled(EFI_PARAVIRT) use

* 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: > > > > arch/arm/xen/enlighten.c

Re: efi_enabled(EFI_PARAVIRT) use

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: > > arch/arm/xen/enlighten.c | 6 + >

Re: efi_enabled(EFI_PARAVIRT) use

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: > > arch/arm/xen/enlighten.c | 6 + >

Re: efi_enabled(EFI_PARAVIRT) use

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

Re: efi_enabled(EFI_PARAVIRT) use

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

Re: efi_enabled(EFI_PARAVIRT) use

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 EFI_PARAVIRT but he'll comment himself when he wakes up... :)

Re: efi_enabled(EFI_PARAVIRT) use

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 EFI_PARAVIRT but he'll comment himself when he wakes up... :)

Re: efi_enabled(EFI_PARAVIRT) use

* Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the xen-tip tree got a conflict in: > > drivers/firmware/efi/arm-runtime.c > > between commit: > > 14c43be60166 ("efi/arm*: Drop writable mapping of the UEFI System table") > > from the tip tree

Re: efi_enabled(EFI_PARAVIRT) use

* Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the xen-tip tree got a conflict in: > > drivers/firmware/efi/arm-runtime.c > > between commit: > > 14c43be60166 ("efi/arm*: Drop writable mapping of the UEFI System table") > > from the tip tree and commit: > >