linux-next: manual merge of the xen-tip tree with the tip tree

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

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:

  21c8dfaa2327 ("Xen: EFI: Parse DT parameters for Xen specific UEFI")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/arm-runtime.c
index 17ccf0a8787a,ac609b9f0b99..000000000000
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@@ -109,24 -90,41 +110,30 @@@ static int __init arm_enable_runtime_se
  
  	pr_info("Remapping and enabling EFI services.\n");
  
 -	mapsize = memmap.map_end - memmap.map;
 -	memmap.map = (__force void *)ioremap_cache(memmap.phys_map,
 -						   mapsize);
 -	if (!memmap.map) {
 -		pr_err("Failed to remap EFI memory map\n");
 -		return -ENOMEM;
 -	}
 -	memmap.map_end = memmap.map + mapsize;
 -	efi.memmap = &memmap;
 +	mapsize = efi.memmap.map_end - efi.memmap.map;
  
 -	efi.systab = (__force void *)ioremap_cache(efi_system_table,
 -						   sizeof(efi_system_table_t));
 -	if (!efi.systab) {
 -		pr_err("Failed to remap EFI System Table\n");
 +	efi.memmap.map = memremap(efi.memmap.phys_map, mapsize, MEMREMAP_WB);
 +	if (!efi.memmap.map) {
 +		pr_err("Failed to remap EFI memory map\n");
  		return -ENOMEM;
  	}
 -	set_bit(EFI_SYSTEM_TABLES, &efi.flags);
 +	efi.memmap.map_end = efi.memmap.map + mapsize;
  
- 	if (!efi_virtmap_init()) {
- 		pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
- 		return -ENOMEM;
+ 	if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+ 		/* Set up runtime services function pointers for Xen Dom0 */
+ 		xen_efi_runtime_setup();
+ 	} else {
+ 		if (!efi_virtmap_init()) {
 -			pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
++			pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
+ 			return -ENOMEM;
+ 		}
+ 
+ 		/* Set up runtime services function pointers */
+ 		efi_native_runtime_setup();
  	}
  
- 	/* Set up runtime services function pointers */
- 	efi_native_runtime_setup();
  	set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
  
 -	efi.runtime_version = efi.systab->hdr.revision;
 -
  	return 0;
  }
  early_initcall(arm_enable_runtime_services);

Re: efi_enabled(EFI_PARAVIRT) use

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> 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:
> 
>   21c8dfaa2327 ("Xen: EFI: Parse DT parameters for Xen specific UEFI")
> 
> from the xen-tip tree.

(I've attached 21c8dfaa2327 below, for reference.)

Argh:

With considerable pain we just got rid of paravirt_enabled() in the x86 tree, and 
Xen is now reintroducing it in the EFI code. Please don't: if you have to do 
capability flags then name the flag accordingly to what it does, don't use some 
generic catch-all naming that will inevitably cause the kind of problems 
paravirt_enabled() caused...

So: NAKed-by: Ingo Molnar <mingo@kernel.org>

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 +++++
 drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
 drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
 3 files changed, 56 insertions(+), 12 deletions(-)

in the EFI tree.

Thanks,

	Ingo

=======================>
>From 21c8dfaa23276be2ae6d580331d8d252cc41e8d9 Mon Sep 17 00:00:00 2001
From: Shannon Zhao <shannon.zhao@linaro.org>
Date: Thu, 7 Apr 2016 20:03:34 +0800
Subject: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.

If Xen supports EFI, initialize runtime services.

CC: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Julien Grall <julien.grall@arm.com>
---
 arch/arm/xen/enlighten.c           |  6 +++++
 drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
 drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 13e3e9f9b094..e130562d3283 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
 	    !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
 		hyper_node.version = s + strlen(hyper_node.prefix);
 
+	if (IS_ENABLED(CONFIG_XEN_EFI)) {
+		/* Check if Xen supports EFI */
+		if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+			set_bit(EFI_PARAVIRT, &efi.flags);
+	}
+
 	return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 6ae21e41a429..ac609b9f0b99 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
 #include <asm/mmu.h>
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
+#include <asm/xen/xen-ops.h>
 
 extern u64 efi_system_table;
 
@@ -107,13 +108,19 @@ static int __init arm_enable_runtime_services(void)
 	}
 	set_bit(EFI_SYSTEM_TABLES, &efi.flags);
 
-	if (!efi_virtmap_init()) {
-		pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
-		return -ENOMEM;
+	if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+		/* Set up runtime services function pointers for Xen Dom0 */
+		xen_efi_runtime_setup();
+	} else {
+		if (!efi_virtmap_init()) {
+			pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
+			return -ENOMEM;
+		}
+
+		/* Set up runtime services function pointers */
+		efi_native_runtime_setup();
 	}
 
-	/* Set up runtime services function pointers */
-	efi_native_runtime_setup();
 	set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
 
 	efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3a69ed5ecfcb..519c096a7c33 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -469,12 +469,14 @@ device_initcall(efi_load_efivars);
 		FIELD_SIZEOF(struct efi_fdt_params, field) \
 	}
 
-static __initdata struct {
+struct params {
 	const char name[32];
 	const char propname[32];
 	int offset;
 	int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
 	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
 	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
 	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -482,24 +484,45 @@ static __initdata struct {
 	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static struct params xen_fdt_params[] __initdata = {
+	UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+	UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+	UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+	UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+	UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
 struct param_info {
 	int found;
 	void *params;
+	struct params *dt_params;
+	int size;
 };
 
 static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
 				       int depth, void *data)
 {
 	struct param_info *info = data;
+	struct params *dt_params = info->dt_params;
 	const void *prop;
 	void *dest;
 	u64 val;
-	int i, len;
+	int i, len, offset;
 
-	if (depth != 1 || strcmp(uname, "chosen") != 0)
-		return 0;
+	if (efi_enabled(EFI_PARAVIRT)) {
+		if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+			return 0;
 
-	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+		offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+		if (offset < 0)
+			return 0;
+		node = offset;
+	} else {
+		if (depth != 1 || strcmp(uname, "chosen") != 0)
+			return 0;
+	}
+
+	for (i = 0; i < info->size; i++) {
 		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
 		if (!prop)
 			return 0;
@@ -530,12 +553,20 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
 	info.found = 0;
 	info.params = params;
 
+	if (efi_enabled(EFI_PARAVIRT)) {
+		info.dt_params = xen_fdt_params;
+		info.size = ARRAY_SIZE(xen_fdt_params);
+	} else {
+		info.dt_params = fdt_params;
+		info.size = ARRAY_SIZE(fdt_params);
+	}
+
 	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
 	if (!info.found)
 		pr_info("UEFI not found.\n");
 	else if (!ret)
 		pr_err("Can't find '%s' in device tree!\n",
-		       dt_params[info.found].name);
+		       info.dt_params[info.found].name);
 
 	return ret;
 }

Re: efi_enabled(EFI_PARAVIRT) use

[Borislav Petkov]

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

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: efi_enabled(EFI_PARAVIRT) use

[Matt Fleming]

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

Yeah, I haven't actually got around to dropping EFI_PARAVIRT yet but
since it's basically used to skip certain initialisation operations on
boot I figured we could just provide empty stub functions as part of
struct efi (probably).

The concerns Ingo voiced about EFI_PARAVIRT being a catch-all flag are
very true.

Incidentally kexec and arm64 would need a similar stub functions if we
move more EFI runtime setup code to drivers/firmware/efi, which is my
long-term plan, since neither can call SetVirtualAddressMap().

On x86, I think EFI_PARAVIRT is code for,

  1. Has no EFI memory map
  2. Runtime regions do not need to be mapped
  3. Cannot call SetVirtualAddressMap()
  4. /sys/firmware/efi/fw_vendor is invisible

1. and 2. should be covered by never setting EFI_MEMMAP and
EFI_RUNTIME_SERVICES in efi.flags. We have no bits for 3. and 4. yet.

Re: efi_enabled(EFI_PARAVIRT) use

[Stefano Stabellini]

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 +++++
>  drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
>  drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
>  3 files changed, 56 insertions(+), 12 deletions(-)
> 
> in the EFI tree.

That's true. I'll drop this commit from xentip and let Matt pick it up
or request changes as he sees fit.

Re: efi_enabled(EFI_PARAVIRT) use

[Ingo Molnar]

* Stefano Stabellini <sstabellini@kernel.org> 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           |  6 +++++
> >  drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> >  drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
> >  3 files changed, 56 insertions(+), 12 deletions(-)
> > 
> > in the EFI tree.
> 
> That's true. I'll drop this commit from xentip and let Matt pick it up
> or request changes as he sees fit.

Thanks!

	Ingo

Re: efi_enabled(EFI_PARAVIRT) use

[Matt Fleming]

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:
> > 
> >  arch/arm/xen/enlighten.c           |  6 +++++
> >  drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> >  drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
> >  3 files changed, 56 insertions(+), 12 deletions(-)
> > 
> > in the EFI tree.
> 
> That's true. I'll drop this commit from xentip and let Matt pick it up
> or request changes as he sees fit.

One small change I think would be sensible to make is to expand
EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
Xen, and in the process, to delete EFI_PARAVIRT.

That should address Ingo's major concern, and also make it much easier
to rework the code in a piecemeal fashion.

Could somebody enumerate the things that make Xen (dom0) different on
arm* compared with bare metal EFI boot? The list I made for x86 was,

  1. Has no EFI memory map
  2. Runtime regions do not need to be mapped
  3. Cannot call SetVirtualAddressMap()
  4. /sys/firmware/efi/fw_vendor is invisible

The first maps to not setting EFI_MEMMAP, the second to not setting
EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
to efi.flags that should cover everything on x86. Does arm* require
anything else?

Re: efi_enabled(EFI_PARAVIRT) use

[Ard Biesheuvel]

On 29 April 2016 at 16:39, Matt Fleming <matt@codeblueprint.co.uk> 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 to carry this kind of commit:
>> >
>> >  arch/arm/xen/enlighten.c           |  6 +++++
>> >  drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
>> >  drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
>> >  3 files changed, 56 insertions(+), 12 deletions(-)
>> >
>> > in the EFI tree.
>>
>> That's true. I'll drop this commit from xentip and let Matt pick it up
>> or request changes as he sees fit.
>
> One small change I think would be sensible to make is to expand
> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> Xen, and in the process, to delete EFI_PARAVIRT.
>
> That should address Ingo's major concern, and also make it much easier
> to rework the code in a piecemeal fashion.
>
> Could somebody enumerate the things that make Xen (dom0) different on
> arm* compared with bare metal EFI boot? The list I made for x86 was,
>
>   1. Has no EFI memory map
>   2. Runtime regions do not need to be mapped
>   3. Cannot call SetVirtualAddressMap()
>   4. /sys/firmware/efi/fw_vendor is invisible
>
> The first maps to not setting EFI_MEMMAP, the second to not setting
> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> to efi.flags that should cover everything on x86. Does arm* require
> anything else?

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 installs its paravirtualized alternatives. I
don't remember exactly why that was shot down, though, but I think it
is the only reason this code introduces references to EFI_PARAVIRT in
the first place.

Re: efi_enabled(EFI_PARAVIRT) use

[Stefano Stabellini]

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 to carry this kind of commit:
> > > 
> > >  arch/arm/xen/enlighten.c           |  6 +++++
> > >  drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> > >  drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
> > >  3 files changed, 56 insertions(+), 12 deletions(-)
> > > 
> > > in the EFI tree.
> > 
> > That's true. I'll drop this commit from xentip and let Matt pick it up
> > or request changes as he sees fit.
> 
> One small change I think would be sensible to make is to expand
> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> Xen, and in the process, to delete EFI_PARAVIRT.
> 
> That should address Ingo's major concern, and also make it much easier
> to rework the code in a piecemeal fashion.
> 
> Could somebody enumerate the things that make Xen (dom0) different on
> arm* compared with bare metal EFI boot? The list I made for x86 was,
> 
>   1. Has no EFI memory map
>   2. Runtime regions do not need to be mapped
>   3. Cannot call SetVirtualAddressMap()
>   4. /sys/firmware/efi/fw_vendor is invisible
> 
> The first maps to not setting EFI_MEMMAP, the second to not setting
> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> to efi.flags that should cover everything on x86. Does arm* require
> anything else?

Xen on ARM is different, the impact should be limited:

- there are no BootServices (ExitBootServices has already been called)
- RuntimeServices go via hypercalls

The UEFI memory map is still available at an address specified on device
tree like on native, but the compatibility string is different
("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
than native.

That's pretty much it, Shannon please confirm.

Re: efi_enabled(EFI_PARAVIRT) use

[Stefano Stabellini]

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 
> > > > going to be painful! There's very little reason not to carry this kind of commit:
> > > > 
> > > >  arch/arm/xen/enlighten.c           |  6 +++++
> > > >  drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
> > > >  drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
> > > >  3 files changed, 56 insertions(+), 12 deletions(-)
> > > > 
> > > > in the EFI tree.
> > > 
> > > That's true. I'll drop this commit from xentip and let Matt pick it up
> > > or request changes as he sees fit.
> > 
> > One small change I think would be sensible to make is to expand
> > EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
> > Xen, and in the process, to delete EFI_PARAVIRT.
> > 
> > That should address Ingo's major concern, and also make it much easier
> > to rework the code in a piecemeal fashion.
> > 
> > Could somebody enumerate the things that make Xen (dom0) different on
> > arm* compared with bare metal EFI boot? The list I made for x86 was,
> > 
> >   1. Has no EFI memory map
> >   2. Runtime regions do not need to be mapped
> >   3. Cannot call SetVirtualAddressMap()
> >   4. /sys/firmware/efi/fw_vendor is invisible
> > 
> > The first maps to not setting EFI_MEMMAP, the second to not setting
> > EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
> > to efi.flags that should cover everything on x86. Does arm* require
> > anything else?
> 
> Xen on ARM is different, the impact should be limited:
> 
> - there are no BootServices (ExitBootServices has already been called)
> - RuntimeServices go via hypercalls
> 
> The UEFI memory map is still available at an address specified on device
> tree like on native, but the compatibility string is different
> ("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
> than native.
> 
> That's pretty much it, Shannon please confirm.

This is to say that Xen on ARM might only need EFI_RUNTIME.

Re: efi_enabled(EFI_PARAVIRT) use

[Shannon Zhao]

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 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 +++++
>>>>>  drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
>>>>>  drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
>>>>>  3 files changed, 56 insertions(+), 12 deletions(-)
>>>>>
>>>>> in the EFI tree.
>>>>
>>>> That's true. I'll drop this commit from xentip and let Matt pick it up
>>>> or request changes as he sees fit.
>>>
>>> One small change I think would be sensible to make is to expand
>>> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
>>> Xen, and in the process, to delete EFI_PARAVIRT.
>>>
>>> That should address Ingo's major concern, and also make it much easier
>>> to rework the code in a piecemeal fashion.
>>>
>>> Could somebody enumerate the things that make Xen (dom0) different on
>>> arm* compared with bare metal EFI boot? The list I made for x86 was,
>>>
>>>   1. Has no EFI memory map
>>>   2. Runtime regions do not need to be mapped
>>>   3. Cannot call SetVirtualAddressMap()
>>>   4. /sys/firmware/efi/fw_vendor is invisible
>>>
>>> The first maps to not setting EFI_MEMMAP, the second to not setting
>>> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
>>> to efi.flags that should cover everything on x86. Does arm* require
>>> anything else?
>>
>> Xen on ARM is different, the impact should be limited:
>>
>> - there are no BootServices (ExitBootServices has already been called)
>> - RuntimeServices go via hypercalls
>>
>> The UEFI memory map is still available at an address specified on device
>> tree like on native, but the compatibility string is different
>> ("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
>> than native.
>>
>> That's pretty much it, Shannon please confirm.
> 
> This is to say that Xen on ARM might only need EFI_RUNTIME.
> 
Yes, it needs EFI_RUNTIME_SERVICES.

Thanks,
-- 
Shannon

Re: efi_enabled(EFI_PARAVIRT) use

[Shannon Zhao]

On 2016年04月29日 22:53, Ard Biesheuvel wrote:
> On 29 April 2016 at 16:39, Matt Fleming <matt@codeblueprint.co.uk> 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 to carry this kind of commit:
>>>>
>>>>  arch/arm/xen/enlighten.c           |  6 +++++
>>>>  drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
>>>>  drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
>>>>  3 files changed, 56 insertions(+), 12 deletions(-)
>>>>
>>>> in the EFI tree.
>>>
>>> That's true. I'll drop this commit from xentip and let Matt pick it up
>>> or request changes as he sees fit.
>>
>> One small change I think would be sensible to make is to expand
>> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
>> Xen, and in the process, to delete EFI_PARAVIRT.
>>
Sure. How should I add this change? Rework this patch or add new one on
top of it?

>> That should address Ingo's major concern, and also make it much easier
>> to rework the code in a piecemeal fashion.
>>
>> Could somebody enumerate the things that make Xen (dom0) different on
>> arm* compared with bare metal EFI boot? The list I made for x86 was,
>>
>>   1. Has no EFI memory map
>>   2. Runtime regions do not need to be mapped
>>   3. Cannot call SetVirtualAddressMap()
>>   4. /sys/firmware/efi/fw_vendor is invisible
>>
>> The first maps to not setting EFI_MEMMAP, the second to not setting
>> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
>> to efi.flags that should cover everything on x86. Does arm* require
>> anything else?
> 
> 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 installs its paravirtualized alternatives. I
> don't remember exactly why that was shot down, though, but I think it
> is the only reason this code introduces references to EFI_PARAVIRT in
> the first place.
> 
Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in
fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and then bail
out early in arm_enable_runtime_services() as you said. Then call
xen_efi_runtime_setup() in xen_guest_init().

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 rid of EFI_PARAVIRT. One I
think is that xen_initial_domain() check. Is that fine?

Thanks,
-- 
Shannon

Re: efi_enabled(EFI_PARAVIRT) use

[Matt Fleming]

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 then bail
> out early in arm_enable_runtime_services() as you said. Then call
> xen_efi_runtime_setup() in xen_guest_init().
 
Sounds good.

> 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 rid of EFI_PARAVIRT. One I
> think is that xen_initial_domain() check. Is that fine?

Hmm... why do you actually need to check whether you're running on a
PV machine in fdt_find_uefi_params()? Can't you infer that from the DT
params you discover?

I could understand maybe only accepting the "xen,uefi-system-table"
property if IS_ENABLED(CONFIG_XEN) but surely you don't also need to
filter based on whether you're booting a PV kernel?

Let me put it this way: when would you see "xen,uefi-system-table" and
*not* be booting a PV kernel?

Re: efi_enabled(EFI_PARAVIRT) use

[Shannon Zhao]

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 rid of EFI_PARAVIRT. One I
>> > think is that xen_initial_domain() check. Is that fine?
> Hmm... why do you actually need to check whether you're running on a
> PV machine in fdt_find_uefi_params()?
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.

> Can't you infer that from the DT
> params you discover?
> 

> I could understand maybe only accepting the "xen,uefi-system-table"
> property if IS_ENABLED(CONFIG_XEN) but surely you don't also need to
> filter based on whether you're booting a PV kernel?
> 
> Let me put it this way: when would you see "xen,uefi-system-table" and
> *not* be booting a PV kernel?
So it still needs add another check to firstly parse the fdt to see if
there is "xen,uefi-system-table" under /hypervisor/uefi node, right? I
think it's a bit redundant compared with xen_initial_domain().

Thanks,
-- 
Shannon

Re: efi_enabled(EFI_PARAVIRT) use

[Matt Fleming]

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 you ever expect to see both for
a Dom0 kernel?

> So it still needs add another check to firstly parse the fdt to see if
> there is "xen,uefi-system-table" under /hypervisor/uefi node, right? I
> think it's a bit redundant compared with xen_initial_domain().

Sometimes you really do need to check xen_initial_domain(), but I do
not think this is such a case. And if we can get by without adding
that check, the code will be better for it.

Re: efi_enabled(EFI_PARAVIRT) use

[Shannon Zhao]

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 arrays.
>  
> Why can't you search both nodes? 
Before searching, it needs to decide which uefi params array should be
passed to of_scan_flat_dt().

> Would you ever expect to see both for
> a Dom0 kernel?
> 
>> So it still needs add another check to firstly parse the fdt to see if
>> there is "xen,uefi-system-table" under /hypervisor/uefi node, right? I
>> think it's a bit redundant compared with xen_initial_domain().
> 
> Sometimes you really do need to check xen_initial_domain(), but I do
> not think this is such a case. And if we can get by without adding
> that check, the code will be better for it.
> 
So is there any other way you suggest?

Thanks,
-- 
Shannon

Re: efi_enabled(EFI_PARAVIRT) use

[Matt Fleming]

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
+++ b/drivers/firmware/efi/efi.c
@@ -469,12 +469,14 @@ device_initcall(efi_load_efivars);
 		FIELD_SIZEOF(struct efi_fdt_params, field) \
 	}
 
-static __initdata struct {
+struct params {
 	const char name[32];
 	const char propname[32];
 	int offset;
 	int size;
-} dt_params[] = {
+};
+
+static __initdata struct params fdt_params[] = {
 	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
 	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
 	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -482,44 +484,83 @@ static __initdata struct {
 	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static __initdata struct params xen_fdt_params[] = {
+	UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+	UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+	UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+	UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+	UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
+#define EFI_FDT_PARAMS_SIZE	ARRAY_SIZE(fdt_params)
+
+static __initdata struct {
+	const char *uname;
+	struct params *params;
+} dt_params[] = {
+	{ "hypervisor", xen_fdt_params },
+	{ "chosen", fdt_params },
+};
+
 struct param_info {
 	int found;
 	void *params;
+	const char *missing;
 };
 
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
-				       int depth, void *data)
+static int __init __find_uefi_params(unsigned long node,
+				     struct param_info *info,
+				     struct params *params)
 {
-	struct param_info *info = data;
 	const void *prop;
 	void *dest;
 	u64 val;
 	int i, len;
 
-	if (depth != 1 || strcmp(uname, "chosen") != 0)
-		return 0;
-
-	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
-		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
-		if (!prop)
+	for (i = 0; i < EFI_FDT_PARAMS_SIZE; i++) {
+		prop = of_get_flat_dt_prop(node, params[i].propname, &len);
+		if (!prop) {
+			info->missing = params[i].name;
 			return 0;
-		dest = info->params + dt_params[i].offset;
+		}
+
+		dest = info->params + params[i].offset;
 		info->found++;
 
 		val = of_read_number(prop, len / sizeof(u32));
 
-		if (dt_params[i].size == sizeof(u32))
+		if (params[i].size == sizeof(u32))
 			*(u32 *)dest = val;
 		else
 			*(u64 *)dest = val;
 
 		if (efi_enabled(EFI_DBG))
-			pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
-				dt_params[i].size * 2, val);
+			pr_info("  %s: 0x%0*llx\n", params[i].name,
+				params[i].size * 2, val);
 	}
+
 	return 1;
 }
 
+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 < ARRAY_SIZE(dt_params); i++) {
+
+		if (depth != 1 || strcmp(uname, dt_params[i].uname) != 0) {
+			info->missing = dt_params[i].params[0].name;
+			continue;
+		}
+
+		return __find_uefi_params(node, info, dt_params[i].params);
+	}
+
+	return 0;
+}
+
 int __init efi_get_fdt_params(struct efi_fdt_params *params)
 {
 	struct param_info info;
@@ -535,7 +576,7 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
 		pr_info("UEFI not found.\n");
 	else if (!ret)
 		pr_err("Can't find '%s' in device tree!\n",
-		       dt_params[info.found].name);
+		       info.missing);
 
 	return ret;
 }

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

[Shannon Zhao]

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 3a69ed5ecfcb..13d8be16447a 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -469,12 +469,14 @@ device_initcall(efi_load_efivars);
>  		FIELD_SIZEOF(struct efi_fdt_params, field) \
>  	}
>  
> -static __initdata struct {
> +struct params {
>  	const char name[32];
>  	const char propname[32];
>  	int offset;
>  	int size;
> -} dt_params[] = {
> +};
> +
> +static __initdata struct params fdt_params[] = {
>  	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
>  	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
>  	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
> @@ -482,44 +484,83 @@ static __initdata struct {
>  	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
>  };
>  
> +static __initdata struct params xen_fdt_params[] = {
> +	UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
> +	UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
> +	UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
> +	UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
> +	UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
> +};
> +
> +#define EFI_FDT_PARAMS_SIZE	ARRAY_SIZE(fdt_params)
> +
> +static __initdata struct {
> +	const char *uname;
> +	struct params *params;
> +} dt_params[] = {
> +	{ "hypervisor", xen_fdt_params },
While the uefi params are located under /hypervisor/uefi node not
/hypervisor node.

> +	{ "chosen", fdt_params },
> +};
> +
>  struct param_info {
>  	int found;
>  	void *params;
> +	const char *missing;
>  };
>  
> -static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
> -				       int depth, void *data)
> +static int __init __find_uefi_params(unsigned long node,
> +				     struct param_info *info,
> +				     struct params *params)
>  {
> -	struct param_info *info = data;
>  	const void *prop;
>  	void *dest;
>  	u64 val;
>  	int i, len;
>  
> -	if (depth != 1 || strcmp(uname, "chosen") != 0)
> -		return 0;
> -
> -	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
> -		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
> -		if (!prop)
> +	for (i = 0; i < EFI_FDT_PARAMS_SIZE; i++) {
> +		prop = of_get_flat_dt_prop(node, params[i].propname, &len);
> +		if (!prop) {
> +			info->missing = params[i].name;
>  			return 0;
> -		dest = info->params + dt_params[i].offset;
> +		}
> +
> +		dest = info->params + params[i].offset;
>  		info->found++;
>  
>  		val = of_read_number(prop, len / sizeof(u32));
>  
> -		if (dt_params[i].size == sizeof(u32))
> +		if (params[i].size == sizeof(u32))
>  			*(u32 *)dest = val;
>  		else
>  			*(u64 *)dest = val;
>  
>  		if (efi_enabled(EFI_DBG))
> -			pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
> -				dt_params[i].size * 2, val);
> +			pr_info("  %s: 0x%0*llx\n", params[i].name,
> +				params[i].size * 2, val);
>  	}
> +
>  	return 1;
>  }
>  
> +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 < ARRAY_SIZE(dt_params); i++) {
> +
> +		if (depth != 1 || strcmp(uname, dt_params[i].uname) != 0) {
> +			info->missing = dt_params[i].params[0].name;
> +			continue;
> +		}
> +
So here it needs to check whether the node is /hypervisor. If so, get
the subnode "uefi". Like below:
if (strcmp(uname, "hypervisor") == 0) {
	offset = of_get_flat_dt_subnode_by_name(node, "uefi");
	if (offset < 0)
		return 0;
	node = offset;
}

> +		return __find_uefi_params(node, info, dt_params[i].params);
> +	}
> +
> +	return 0;
> +}
> +
>  int __init efi_get_fdt_params(struct efi_fdt_params *params)
>  {
>  	struct param_info info;
> @@ -535,7 +576,7 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
>  		pr_info("UEFI not found.\n");
>  	else if (!ret)
>  		pr_err("Can't find '%s' in device tree!\n",
> -		       dt_params[info.found].name);
> +		       info.missing);
>  
>  	return ret;
>  }
> 

-- 
Shannon

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

[Shannon Zhao]

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 installs its paravirtualized alternatives. I
>> > don't remember exactly why that was shot down, though, but I think it
>> > is the only reason this code introduces references to EFI_PARAVIRT in
>> > the first place.
>> > 
> Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in
> fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and then bail
> out early in arm_enable_runtime_services() as you said. Then call
> xen_efi_runtime_setup() in xen_guest_init().

Hi Ard,

If it sets EFI_RUNTIME_SERVICES flag in fdt_find_hyper_node and in
arm_enable_runtime_services() it checks whether it's a Dom0 through
xen_init_domain() and the EFI_RUNTIME_SERVICES flag is set, then call
xen_efi_runtime_setup(). Is it ok?

Thanks,
-- 
Shannon

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

[Matt Fleming]

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 < ARRAY_SIZE(dt_params); i++) {
> > +
> > +		if (depth != 1 || strcmp(uname, dt_params[i].uname) != 0) {
> > +			info->missing = dt_params[i].params[0].name;
> > +			continue;
> > +		}
> > +
> So here it needs to check whether the node is /hypervisor. If so, get
> the subnode "uefi". Like below:
> if (strcmp(uname, "hypervisor") == 0) {
> 	offset = of_get_flat_dt_subnode_by_name(node, "uefi");
> 	if (offset < 0)
> 		return 0;
> 	node = offset;
> }

Urgh, right.

How about giving dt_params a const char *subnode field and doing,

	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
		const char *subnode = dt_params[i].sub_node;

		if (depth != 1 || strcmp(uname, dt_params[i].uname) != 0) {
			info->missing = dt_params[i].params[0].name;
			continue;
		}

		if (subnode) {
			offset = of_get_flat_dt_subnode_by_name(node, subnode);
			if (offset < 0)
				return 0;
			node = offset;
		}

	...

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/irq.c

between commits:

  20125c872a3f ("x86/xen: Make save_fl() noinstr")
  d7bfc7d57cbe ("x86/xen: Make irq_enable() noinstr")
  09c413071e2d ("x86/xen: Make irq_disable() noinstr")
  1462eb381b4c ("x86/xen: Rework the xen_{cpu,irq,mmu}_opsarrays")

from the tip tree and commit:

  97c79d816979 ("x86/xen: switch initial pvops IRQ functions to dummy ones")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

There may be more required, though.
-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/xen/irq.c
index 4fe387e520af,ae8537583102..000000000000
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@@ -94,16 -40,14 +40,16 @@@ static void xen_halt(void
  		xen_safe_halt();
  }
  
 -static const struct pv_irq_ops xen_irq_ops __initconst = {
 -	/* Initial interrupt flag handling only called while interrupts off. */
 -	.save_fl = __PV_IS_CALLEE_SAVE(paravirt_ret0),
 -	.irq_disable = __PV_IS_CALLEE_SAVE(paravirt_nop),
 -	.irq_enable = __PV_IS_CALLEE_SAVE(paravirt_BUG),
 +static const typeof(pv_ops) xen_irq_ops __initconst = {
 +	.irq = {
- 
- 		.save_fl = PV_CALLEE_SAVE(xen_save_fl),
- 		.irq_disable = PV_CALLEE_SAVE(xen_irq_disable),
- 		.irq_enable = PV_CALLEE_SAVE(xen_irq_enable),
++		/* Initial interrupt flag handling only called while interrupts off. */
++		.save_fl = __PV_IS_CALLEE_SAVE(paravirt_ret0),
++		.irq_disable = __PV_IS_CALLEE_SAVE(paravirt_nop),
++		.irq_enable = __PV_IS_CALLEE_SAVE(paravirt_BUG),
  
 -	.safe_halt = xen_safe_halt,
 -	.halt = xen_halt,
 +		.safe_halt = xen_safe_halt,
 +		.halt = xen_halt,
 +	},
  };
  
  void __init xen_init_irq_ops(void)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Thomas Gleixner]

On Thu, 31 Aug 2017, Boris Ostrovsky wrote:

> On 08/31/2017 08:00 AM, Thomas Gleixner wrote:
> > On Thu, 31 Aug 2017, Juergen Gross wrote:
> >>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts
> >>> mindlessly. Patch below.
> >>>
> >>> Juergen, can you please check the result?
> >> You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
> >> of the xen specific trap entries in arch/x86/include/asm/traps.h
> > I'll try that again later today, unless you beat me to it.
> >
> 
> https://marc.info/?l=linux-kernel&m=150296063131595&w=2 should also be
> picked up by the tip tree then since it applies on top of the
> adjust_exception_frame patch. I will revert it from Xen tree as well.

Juergen folded that fix in and posted a version against tip:x86/apic. It's
applied and pushed out now.

Thanks to everyone helping with this.

       tglx

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 31/08/17 16:01, Boris Ostrovsky wrote:
> On 08/31/2017 08:00 AM, Thomas Gleixner wrote:
>> On Thu, 31 Aug 2017, Juergen Gross wrote:
>>>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts
>>>> mindlessly. Patch below.
>>>>
>>>> Juergen, can you please check the result?
>>> You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
>>> of the xen specific trap entries in arch/x86/include/asm/traps.h
>> I'll try that again later today, unless you beat me to it.
>>
> 
> https://marc.info/?l=linux-kernel&m=150296063131595&w=2 should also be
> picked up by the tip tree then since it applies on top of the
> adjust_exception_frame patch. I will revert it from Xen tree as well.

I have included this patch in my rebase on top of the tip tree, so it is
no longer needed.


Juergen

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Boris Ostrovsky]

On 08/31/2017 08:00 AM, Thomas Gleixner wrote:
> On Thu, 31 Aug 2017, Juergen Gross wrote:
>>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts
>>> mindlessly. Patch below.
>>>
>>> Juergen, can you please check the result?
>> You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
>> of the xen specific trap entries in arch/x86/include/asm/traps.h
> I'll try that again later today, unless you beat me to it.
>

https://marc.info/?l=linux-kernel&m=150296063131595&w=2 should also be
picked up by the tip tree then since it applies on top of the
adjust_exception_frame patch. I will revert it from Xen tree as well.

-boris

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Joe Perches]

On Thu, 2017-08-31 at 11:16 +0200, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> Low prio nitpicking, could we please write such table based initializers in a 
> vertically organized, tabular fashion:
> 
> > +	{ debug,			xen_xendebug,				true },
> > +	{ int3,				xen_xenint3,				true },
> > +	{ double_fault,			xen_double_fault,			true },
> > +#ifdef CONFIG_X86_MCE
> > +	{ machine_check,		xen_machine_check,			true },
> > +#endif
> > +	{ nmi,				xen_nmi,				true },
> > +	{ overflow,			xen_overflow,				false },
> > +#ifdef CONFIG_IA32_EMULATION
> > +	{ entry_INT80_compat,		xen_entry_INT80_compat,			false },
> > +#endif
> > +	{ page_fault,			xen_page_fault,				false },
> > +	{ divide_error,			xen_divide_error,			false },
> > +	{ bounds,			xen_bounds,				false },
> > +	{ invalid_op,			xen_invalid_op,				false },
> > +	{ device_not_available,		xen_device_not_available,		false },
> > +	{ coprocessor_segment_overrun,	xen_coprocessor_segment_overrun,	false },
> > +	{ invalid_TSS,			xen_invalid_TSS,			false },
> > +	{ segment_not_present,		xen_segment_not_present,		false },
> > +	{ stack_segment,		xen_stack_segment,			false },
> > +	{ general_protection,		xen_general_protection,			false },
> > +	{ spurious_interrupt_bug,	xen_spurious_interrupt_bug,		false },
> > +	{ coprocessor_error,		xen_coprocessor_error,			false },
> > +	{ alignment_check,		xen_alignment_check,			false },
> > +	{ simd_coprocessor_error,	xen_simd_coprocessor_error,		false },
> > +#ifdef CONFIG_TRACING
> > +	{ trace_page_fault,		xen_trace_page_fault,			false },
> > +#endif
> ,,
> ... as to me such a table is 100 times more readable - YMMV.

Yeah, kinda.

It's a lot of whitespace and eyeball left/right scanning.
And these tables require whitespace updating if a longer
name is ever used.

Given the near 1:1 mapping of <trap> to xen_<trap>
perhaps adding a macro would be nice.

#define xen_trap(trap, ist_ok) \
	{ trap, xen_##trap, ist_ok }

	{ debug,	xen_xendebug,	true },
	{ int3,		xen_xenint3,	true },
#ifdef CONFIG_X86_MCE
	xen_trap(machine_check, true),
#endif
	xen_trap(double_fault, true),
	xen_trap(nmi, true),
	xen_trap(overflow, false),
	...

ymmv. </bikeshedding>

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Thomas Gleixner]

On Thu, 31 Aug 2017, Juergen Gross wrote:
> > I've applied it on top of tip:x86/apic and fixed up the merge conflicts
> > mindlessly. Patch below.
> > 
> > Juergen, can you please check the result?
> 
> You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
> of the xen specific trap entries in arch/x86/include/asm/traps.h

I'll try that again later today, unless you beat me to it.

Thanks,

	tglx

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 31/08/17 11:00, Thomas Gleixner wrote:
> On Thu, 31 Aug 2017, Thomas Gleixner wrote:
>> Hrm. For some reason I missed to remove these defines after getting rid of
>> the tracing idt.
>>
>> I'll remove that now in tip and pull in the XEN stuff to see what needs to
>> be done.
> 
> I pushed out the removal of the trace leftovers. Talked to Juergen on IRC
> and he suggested to revert the XEN patch in the xen tree and merge it
> through tip.
> 
> I've applied it on top of tip:x86/apic and fixed up the merge conflicts
> mindlessly. Patch below.
> 
> Juergen, can you please check the result?
> 
> Thanks,
> 
> 	tglx
> 
> 8<-------------
> Subject: xen: Get rid of paravirt op adjust_exception_frame
> From: Juergen Gross <jgross@suse.com>
> Date: Fri, 11 Aug 2017 16:54:48 +0200
> 
> When running as Xen pv-guest the exception frame on the stack contains
> %r11 and %rcx additional to the other data pushed by the processor.
> 
> Instead of having a paravirt op being called for each exception type
> prepend the Xen specific code to each exception entry. When running as
> Xen pv-guest just use the exception entry with prepended instructions,
> otherwise use the entry without the Xen specific code.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Cc: xen-devel@lists.xenproject.org
> Cc: boris.ostrovsky@oracle.com
> Cc: luto@amacapital.net
> Link: http://lkml.kernel.org/r/20170811145448.5679-1-jgross@suse.com
> 
> ---
>  arch/x86/entry/entry_64.S             |   11 +--
>  arch/x86/entry/entry_64_compat.S      |    1 
>  arch/x86/include/asm/paravirt.h       |    5 -
>  arch/x86/include/asm/paravirt_types.h |    4 -
>  arch/x86/include/asm/proto.h          |    3 +
>  arch/x86/include/asm/traps.h          |    3 -
>  arch/x86/kernel/asm-offsets_64.c      |    1 
>  arch/x86/kernel/paravirt.c            |    3 -
>  arch/x86/xen/enlighten_pv.c           |   96 ++++++++++++++++++++++------------
>  arch/x86/xen/irq.c                    |    3 -
>  arch/x86/xen/xen-ops.h                |    1 
>  11 files changed, 70 insertions(+), 61 deletions(-)
> 
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -816,7 +816,6 @@ ENTRY(\sym)
>  	.endif
>  
>  	ASM_CLAC
> -	PARAVIRT_ADJUST_EXCEPTION_FRAME
>  
>  	.ifeq \has_error_code
>  	pushq	$-1				/* ORIG_RAX: no syscall to restart */
> @@ -962,7 +961,7 @@ ENTRY(do_softirq_own_stack)
>  ENDPROC(do_softirq_own_stack)
>  
>  #ifdef CONFIG_XEN
> -idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
> +idtentry hypervisor_callback xen_do_hypervisor_callback has_error_code=0
>  
>  /*
>   * A note on the "critical region" in our callback handler.
> @@ -1029,8 +1028,6 @@ ENTRY(xen_failsafe_callback)
>  	movq	8(%rsp), %r11
>  	addq	$0x30, %rsp
>  	pushq	$0				/* RIP */
> -	pushq	%r11
> -	pushq	%rcx
>  	UNWIND_HINT_IRET_REGS offset=8
>  	jmp	general_protection
>  1:	/* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */
> @@ -1061,9 +1058,8 @@ idtentry int3			do_int3			has_error_code
>  idtentry stack_segment		do_stack_segment	has_error_code=1
>  
>  #ifdef CONFIG_XEN
> -idtentry xen_debug		do_debug		has_error_code=0
> -idtentry xen_int3		do_int3			has_error_code=0
> -idtentry xen_stack_segment	do_stack_segment	has_error_code=1
> +idtentry xendebug		do_debug		has_error_code=0
> +idtentry xenint3		do_int3			has_error_code=0
>  #endif
>  
>  idtentry general_protection	do_general_protection	has_error_code=1
> @@ -1227,6 +1223,7 @@ ENTRY(error_exit)
>  END(error_exit)
>  
>  /* Runs on exception stack */
> +/* XXX: broken on Xen PV */
>  ENTRY(nmi)
>  	UNWIND_HINT_IRET_REGS
>  	/*
> --- a/arch/x86/entry/entry_64_compat.S
> +++ b/arch/x86/entry/entry_64_compat.S
> @@ -293,7 +293,6 @@ ENTRY(entry_INT80_compat)
>  	/*
>  	 * Interrupts are off on entry.
>  	 */
> -	PARAVIRT_ADJUST_EXCEPTION_FRAME
>  	ASM_CLAC			/* Do this early to minimize exposure */
>  	SWAPGS
>  
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -960,11 +960,6 @@ extern void default_banner(void);
>  #define GET_CR2_INTO_RAX				\
>  	call PARA_INDIRECT(pv_mmu_ops+PV_MMU_read_cr2)
>  
> -#define PARAVIRT_ADJUST_EXCEPTION_FRAME					\
> -	PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_adjust_exception_frame), \
> -		  CLBR_NONE,						\
> -		  call PARA_INDIRECT(pv_irq_ops+PV_IRQ_adjust_exception_frame))
> -
>  #define USERGS_SYSRET64							\
>  	PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64),	\
>  		  CLBR_NONE,						\
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -195,10 +195,6 @@ struct pv_irq_ops {
>  
>  	void (*safe_halt)(void);
>  	void (*halt)(void);
> -
> -#ifdef CONFIG_X86_64
> -	void (*adjust_exception_frame)(void);
> -#endif
>  } __no_randomize_layout;
>  
>  struct pv_mmu_ops {
> --- a/arch/x86/include/asm/proto.h
> +++ b/arch/x86/include/asm/proto.h
> @@ -24,6 +24,9 @@ void entry_SYSENTER_compat(void);
>  void __end_entry_SYSENTER_compat(void);
>  void entry_SYSCALL_compat(void);
>  void entry_INT80_compat(void);
> +#if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
> +void xen_entry_INT80_compat(void);
> +#endif
>  #endif
>  
>  void x86_configure_nx(void);
> --- a/arch/x86/include/asm/traps.h
> +++ b/arch/x86/include/asm/traps.h
> @@ -13,9 +13,6 @@ asmlinkage void divide_error(void);
>  asmlinkage void debug(void);
>  asmlinkage void nmi(void);
>  asmlinkage void int3(void);
> -asmlinkage void xen_debug(void);
> -asmlinkage void xen_int3(void);
> -asmlinkage void xen_stack_segment(void);
>  asmlinkage void overflow(void);
>  asmlinkage void bounds(void);
>  asmlinkage void invalid_op(void);
> --- a/arch/x86/kernel/asm-offsets_64.c
> +++ b/arch/x86/kernel/asm-offsets_64.c
> @@ -20,7 +20,6 @@ static char syscalls_ia32[] = {
>  int main(void)
>  {
>  #ifdef CONFIG_PARAVIRT
> -	OFFSET(PV_IRQ_adjust_exception_frame, pv_irq_ops, adjust_exception_frame);
>  	OFFSET(PV_CPU_usergs_sysret64, pv_cpu_ops, usergs_sysret64);
>  	OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs);
>  	BLANK();
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -319,9 +319,6 @@ struct pv_time_ops pv_time_ops = {
>  	.irq_enable = __PV_IS_CALLEE_SAVE(native_irq_enable),
>  	.safe_halt = native_safe_halt,
>  	.halt = native_halt,
> -#ifdef CONFIG_X86_64
> -	.adjust_exception_frame = paravirt_nop,
> -#endif
>  };
>  
>  __visible struct pv_cpu_ops pv_cpu_ops = {
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -586,6 +586,68 @@ static void xen_write_ldt_entry(struct d
>  	preempt_enable();
>  }
>  
> +#ifdef CONFIG_X86_64
> +static struct {
> +	void (*orig)(void);
> +	void (*xen)(void);
> +	bool ist_okay;
> +} trap_array[] = {
> +	{ debug, xen_xendebug, true },
> +	{ int3, xen_xenint3, true },
> +	{ double_fault, xen_double_fault, true },
> +#ifdef CONFIG_X86_MCE
> +	{ machine_check, xen_machine_check, true },
> +#endif
> +	{ nmi, xen_nmi, true },
> +	{ overflow, xen_overflow, false },
> +#ifdef CONFIG_IA32_EMULATION
> +	{ entry_INT80_compat, xen_entry_INT80_compat, false },
> +#endif
> +	{ page_fault, xen_page_fault, false },
> +	{ divide_error, xen_divide_error, false },
> +	{ bounds, xen_bounds, false },
> +	{ invalid_op, xen_invalid_op, false },
> +	{ device_not_available, xen_device_not_available, false },
> +	{ coprocessor_segment_overrun, xen_coprocessor_segment_overrun, false },
> +	{ invalid_TSS, xen_invalid_TSS, false },
> +	{ segment_not_present, xen_segment_not_present, false },
> +	{ stack_segment, xen_stack_segment, false },
> +	{ general_protection, xen_general_protection, false },
> +	{ spurious_interrupt_bug, xen_spurious_interrupt_bug, false },
> +	{ coprocessor_error, xen_coprocessor_error, false },
> +	{ alignment_check, xen_alignment_check, false },
> +	{ simd_coprocessor_error, xen_simd_coprocessor_error, false },
> +#ifdef CONFIG_TRACING
> +	{ trace_page_fault, xen_trace_page_fault, false },
> +#endif
> +};
> +
> +static bool get_trap_addr(unsigned long *addr, unsigned int ist)
> +{
> +	unsigned int nr;
> +	bool ist_okay = false;
> +
> +	/*
> +	 * Replace trap handler addresses by Xen specific ones.
> +	 * Check for known traps using IST and whitelist them.
> +	 * The debugger ones are the only ones we care about.
> +	 * Xen will handle faults like double_fault, * so we should never see
> +	 * them.  Warn if there's an unexpected IST-using fault handler.
> +	 */
> +	for (nr = 0; nr < ARRAY_SIZE(trap_array); nr++)
> +		if (*addr == (unsigned long)trap_array[nr].orig) {
> +			*addr = (unsigned long)trap_array[nr].xen;
> +			ist_okay = trap_array[nr].ist_okay;
> +			break;
> +		}
> +
> +	if (WARN_ON(ist != 0 && !ist_okay))
> +		return false;
> +
> +	return true;
> +}
> +#endif
> +
>  static int cvt_gate_to_trap(int vector, const gate_desc *val,
>  			    struct trap_info *info)
>  {
> @@ -598,40 +660,8 @@ static int cvt_gate_to_trap(int vector,
>  
>  	addr = gate_offset(val);
>  #ifdef CONFIG_X86_64
> -	/*
> -	 * Look for known traps using IST, and substitute them
> -	 * appropriately.  The debugger ones are the only ones we care
> -	 * about.  Xen will handle faults like double_fault,
> -	 * so we should never see them.  Warn if
> -	 * there's an unexpected IST-using fault handler.
> -	 */
> -	if (addr == (unsigned long)debug)
> -		addr = (unsigned long)xen_debug;
> -	else if (addr == (unsigned long)int3)
> -		addr = (unsigned long)xen_int3;
> -	else if (addr == (unsigned long)stack_segment)
> -		addr = (unsigned long)xen_stack_segment;
> -	else if (addr == (unsigned long)double_fault) {
> -		/* Don't need to handle these */
> +	if (!get_trap_addr(&addr, val->bits.ist))
>  		return 0;
> -#ifdef CONFIG_X86_MCE
> -	} else if (addr == (unsigned long)machine_check) {
> -		/*
> -		 * when xen hypervisor inject vMCE to guest,
> -		 * use native mce handler to handle it
> -		 */
> -		;
> -#endif
> -	} else if (addr == (unsigned long)nmi)
> -		/*
> -		 * Use the native version as well.
> -		 */
> -		;
> -	else {
> -		/* Some other trap using IST? */
> -		if (WARN_ON(val->bits.ist != 0))
> -			return 0;
> -	}
>  #endif	/* CONFIG_X86_64 */
>  	info->address = addr;
>  
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -123,9 +123,6 @@ static const struct pv_irq_ops xen_irq_o
>  
>  	.safe_halt = xen_safe_halt,
>  	.halt = xen_halt,
> -#ifdef CONFIG_X86_64
> -	.adjust_exception_frame = xen_adjust_exception_frame,
> -#endif
>  };
>  
>  void __init xen_init_irq_ops(void)
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -138,7 +138,6 @@ static inline void __init xen_efi_init(v
>  __visible void xen_iret(void);
>  __visible void xen_sysret32(void);
>  __visible void xen_sysret64(void);
> -__visible void xen_adjust_exception_frame(void);
>  
>  extern int xen_panic_handler_init(void);
>  
> 

You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
of the xen specific trap entries in arch/x86/include/asm/traps.h


Juergen

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -586,6 +586,68 @@ static void xen_write_ldt_entry(struct d
>  	preempt_enable();
>  }
>  
> +#ifdef CONFIG_X86_64
> +static struct {
> +	void (*orig)(void);
> +	void (*xen)(void);
> +	bool ist_okay;
> +} trap_array[] = {
> +	{ debug, xen_xendebug, true },
> +	{ int3, xen_xenint3, true },
> +	{ double_fault, xen_double_fault, true },
> +#ifdef CONFIG_X86_MCE
> +	{ machine_check, xen_machine_check, true },
> +#endif
> +	{ nmi, xen_nmi, true },
> +	{ overflow, xen_overflow, false },
> +#ifdef CONFIG_IA32_EMULATION
> +	{ entry_INT80_compat, xen_entry_INT80_compat, false },
> +#endif
> +	{ page_fault, xen_page_fault, false },
> +	{ divide_error, xen_divide_error, false },
> +	{ bounds, xen_bounds, false },
> +	{ invalid_op, xen_invalid_op, false },
> +	{ device_not_available, xen_device_not_available, false },
> +	{ coprocessor_segment_overrun, xen_coprocessor_segment_overrun, false },
> +	{ invalid_TSS, xen_invalid_TSS, false },
> +	{ segment_not_present, xen_segment_not_present, false },
> +	{ stack_segment, xen_stack_segment, false },
> +	{ general_protection, xen_general_protection, false },
> +	{ spurious_interrupt_bug, xen_spurious_interrupt_bug, false },
> +	{ coprocessor_error, xen_coprocessor_error, false },
> +	{ alignment_check, xen_alignment_check, false },
> +	{ simd_coprocessor_error, xen_simd_coprocessor_error, false },
> +#ifdef CONFIG_TRACING
> +	{ trace_page_fault, xen_trace_page_fault, false },
> +#endif
> +};

Low prio nitpicking, could we please write such table based initializers in a 
vertically organized, tabular fashion:

> +	{ debug,			xen_xendebug,				true },
> +	{ int3,				xen_xenint3,				true },
> +	{ double_fault,			xen_double_fault,			true },
> +#ifdef CONFIG_X86_MCE
> +	{ machine_check,		xen_machine_check,			true },
> +#endif
> +	{ nmi,				xen_nmi,				true },
> +	{ overflow,			xen_overflow,				false },
> +#ifdef CONFIG_IA32_EMULATION
> +	{ entry_INT80_compat,		xen_entry_INT80_compat,			false },
> +#endif
> +	{ page_fault,			xen_page_fault,				false },
> +	{ divide_error,			xen_divide_error,			false },
> +	{ bounds,			xen_bounds,				false },
> +	{ invalid_op,			xen_invalid_op,				false },
> +	{ device_not_available,		xen_device_not_available,		false },
> +	{ coprocessor_segment_overrun,	xen_coprocessor_segment_overrun,	false },
> +	{ invalid_TSS,			xen_invalid_TSS,			false },
> +	{ segment_not_present,		xen_segment_not_present,		false },
> +	{ stack_segment,		xen_stack_segment,			false },
> +	{ general_protection,		xen_general_protection,			false },
> +	{ spurious_interrupt_bug,	xen_spurious_interrupt_bug,		false },
> +	{ coprocessor_error,		xen_coprocessor_error,			false },
> +	{ alignment_check,		xen_alignment_check,			false },
> +	{ simd_coprocessor_error,	xen_simd_coprocessor_error,		false },
> +#ifdef CONFIG_TRACING
> +	{ trace_page_fault,		xen_trace_page_fault,			false },
> +#endif

... as to me such a table is 100 times more readable - YMMV.

(If checkpatch whinges about col80 then ignore it.)

> +
> +static bool get_trap_addr(unsigned long *addr, unsigned int ist)
> +{
> +	unsigned int nr;
> +	bool ist_okay = false;
> +
> +	/*
> +	 * Replace trap handler addresses by Xen specific ones.
> +	 * Check for known traps using IST and whitelist them.
> +	 * The debugger ones are the only ones we care about.
> +	 * Xen will handle faults like double_fault, * so we should never see
> +	 * them.  Warn if there's an unexpected IST-using fault handler.
> +	 */
> +	for (nr = 0; nr < ARRAY_SIZE(trap_array); nr++)
> +		if (*addr == (unsigned long)trap_array[nr].orig) {
> +			*addr = (unsigned long)trap_array[nr].xen;
> +			ist_okay = trap_array[nr].ist_okay;
> +			break;
> +		}

And here I think we could do a more readable variant:

  static bool get_trap_addr(void **addr, unsigned int ist)
  ...
		struct trap_array_entry *entry = trap_array + nr;

		if (*addr == entry->orig) {
			*addr = entry->xen;
			ist_okay = entry->ist_okay;
			break;
		}

I believe 'void **' is the natural type that avoids the type casts, and the 
'trap_array_entry' name has to be defined in the array definition further above.

Totally untested though.

Thanks,

	Ingo

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Thomas Gleixner]

On Thu, 31 Aug 2017, Thomas Gleixner wrote:
> Hrm. For some reason I missed to remove these defines after getting rid of
> the tracing idt.
> 
> I'll remove that now in tip and pull in the XEN stuff to see what needs to
> be done.

I pushed out the removal of the trace leftovers. Talked to Juergen on IRC
and he suggested to revert the XEN patch in the xen tree and merge it
through tip.

I've applied it on top of tip:x86/apic and fixed up the merge conflicts
mindlessly. Patch below.

Juergen, can you please check the result?

Thanks,

	tglx

8<-------------
Subject: xen: Get rid of paravirt op adjust_exception_frame
From: Juergen Gross <jgross@suse.com>
Date: Fri, 11 Aug 2017 16:54:48 +0200

When running as Xen pv-guest the exception frame on the stack contains
%r11 and %rcx additional to the other data pushed by the processor.

Instead of having a paravirt op being called for each exception type
prepend the Xen specific code to each exception entry. When running as
Xen pv-guest just use the exception entry with prepended instructions,
otherwise use the entry without the Xen specific code.

Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrovsky@oracle.com
Cc: luto@amacapital.net
Link: http://lkml.kernel.org/r/20170811145448.5679-1-jgross@suse.com

---
 arch/x86/entry/entry_64.S             |   11 +--
 arch/x86/entry/entry_64_compat.S      |    1 
 arch/x86/include/asm/paravirt.h       |    5 -
 arch/x86/include/asm/paravirt_types.h |    4 -
 arch/x86/include/asm/proto.h          |    3 +
 arch/x86/include/asm/traps.h          |    3 -
 arch/x86/kernel/asm-offsets_64.c      |    1 
 arch/x86/kernel/paravirt.c            |    3 -
 arch/x86/xen/enlighten_pv.c           |   96 ++++++++++++++++++++++------------
 arch/x86/xen/irq.c                    |    3 -
 arch/x86/xen/xen-ops.h                |    1 
 11 files changed, 70 insertions(+), 61 deletions(-)

--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -816,7 +816,6 @@ ENTRY(\sym)
 	.endif
 
 	ASM_CLAC
-	PARAVIRT_ADJUST_EXCEPTION_FRAME
 
 	.ifeq \has_error_code
 	pushq	$-1				/* ORIG_RAX: no syscall to restart */
@@ -962,7 +961,7 @@ ENTRY(do_softirq_own_stack)
 ENDPROC(do_softirq_own_stack)
 
 #ifdef CONFIG_XEN
-idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
+idtentry hypervisor_callback xen_do_hypervisor_callback has_error_code=0
 
 /*
  * A note on the "critical region" in our callback handler.
@@ -1029,8 +1028,6 @@ ENTRY(xen_failsafe_callback)
 	movq	8(%rsp), %r11
 	addq	$0x30, %rsp
 	pushq	$0				/* RIP */
-	pushq	%r11
-	pushq	%rcx
 	UNWIND_HINT_IRET_REGS offset=8
 	jmp	general_protection
 1:	/* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */
@@ -1061,9 +1058,8 @@ idtentry int3			do_int3			has_error_code
 idtentry stack_segment		do_stack_segment	has_error_code=1
 
 #ifdef CONFIG_XEN
-idtentry xen_debug		do_debug		has_error_code=0
-idtentry xen_int3		do_int3			has_error_code=0
-idtentry xen_stack_segment	do_stack_segment	has_error_code=1
+idtentry xendebug		do_debug		has_error_code=0
+idtentry xenint3		do_int3			has_error_code=0
 #endif
 
 idtentry general_protection	do_general_protection	has_error_code=1
@@ -1227,6 +1223,7 @@ ENTRY(error_exit)
 END(error_exit)
 
 /* Runs on exception stack */
+/* XXX: broken on Xen PV */
 ENTRY(nmi)
 	UNWIND_HINT_IRET_REGS
 	/*
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -293,7 +293,6 @@ ENTRY(entry_INT80_compat)
 	/*
 	 * Interrupts are off on entry.
 	 */
-	PARAVIRT_ADJUST_EXCEPTION_FRAME
 	ASM_CLAC			/* Do this early to minimize exposure */
 	SWAPGS
 
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -960,11 +960,6 @@ extern void default_banner(void);
 #define GET_CR2_INTO_RAX				\
 	call PARA_INDIRECT(pv_mmu_ops+PV_MMU_read_cr2)
 
-#define PARAVIRT_ADJUST_EXCEPTION_FRAME					\
-	PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_adjust_exception_frame), \
-		  CLBR_NONE,						\
-		  call PARA_INDIRECT(pv_irq_ops+PV_IRQ_adjust_exception_frame))
-
 #define USERGS_SYSRET64							\
 	PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64),	\
 		  CLBR_NONE,						\
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -195,10 +195,6 @@ struct pv_irq_ops {
 
 	void (*safe_halt)(void);
 	void (*halt)(void);
-
-#ifdef CONFIG_X86_64
-	void (*adjust_exception_frame)(void);
-#endif
 } __no_randomize_layout;
 
 struct pv_mmu_ops {
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -24,6 +24,9 @@ void entry_SYSENTER_compat(void);
 void __end_entry_SYSENTER_compat(void);
 void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
+#if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+void xen_entry_INT80_compat(void);
+#endif
 #endif
 
 void x86_configure_nx(void);
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -13,9 +13,6 @@ asmlinkage void divide_error(void);
 asmlinkage void debug(void);
 asmlinkage void nmi(void);
 asmlinkage void int3(void);
-asmlinkage void xen_debug(void);
-asmlinkage void xen_int3(void);
-asmlinkage void xen_stack_segment(void);
 asmlinkage void overflow(void);
 asmlinkage void bounds(void);
 asmlinkage void invalid_op(void);
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -20,7 +20,6 @@ static char syscalls_ia32[] = {
 int main(void)
 {
 #ifdef CONFIG_PARAVIRT
-	OFFSET(PV_IRQ_adjust_exception_frame, pv_irq_ops, adjust_exception_frame);
 	OFFSET(PV_CPU_usergs_sysret64, pv_cpu_ops, usergs_sysret64);
 	OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs);
 	BLANK();
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -319,9 +319,6 @@ struct pv_time_ops pv_time_ops = {
 	.irq_enable = __PV_IS_CALLEE_SAVE(native_irq_enable),
 	.safe_halt = native_safe_halt,
 	.halt = native_halt,
-#ifdef CONFIG_X86_64
-	.adjust_exception_frame = paravirt_nop,
-#endif
 };
 
 __visible struct pv_cpu_ops pv_cpu_ops = {
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -586,6 +586,68 @@ static void xen_write_ldt_entry(struct d
 	preempt_enable();
 }
 
+#ifdef CONFIG_X86_64
+static struct {
+	void (*orig)(void);
+	void (*xen)(void);
+	bool ist_okay;
+} trap_array[] = {
+	{ debug, xen_xendebug, true },
+	{ int3, xen_xenint3, true },
+	{ double_fault, xen_double_fault, true },
+#ifdef CONFIG_X86_MCE
+	{ machine_check, xen_machine_check, true },
+#endif
+	{ nmi, xen_nmi, true },
+	{ overflow, xen_overflow, false },
+#ifdef CONFIG_IA32_EMULATION
+	{ entry_INT80_compat, xen_entry_INT80_compat, false },
+#endif
+	{ page_fault, xen_page_fault, false },
+	{ divide_error, xen_divide_error, false },
+	{ bounds, xen_bounds, false },
+	{ invalid_op, xen_invalid_op, false },
+	{ device_not_available, xen_device_not_available, false },
+	{ coprocessor_segment_overrun, xen_coprocessor_segment_overrun, false },
+	{ invalid_TSS, xen_invalid_TSS, false },
+	{ segment_not_present, xen_segment_not_present, false },
+	{ stack_segment, xen_stack_segment, false },
+	{ general_protection, xen_general_protection, false },
+	{ spurious_interrupt_bug, xen_spurious_interrupt_bug, false },
+	{ coprocessor_error, xen_coprocessor_error, false },
+	{ alignment_check, xen_alignment_check, false },
+	{ simd_coprocessor_error, xen_simd_coprocessor_error, false },
+#ifdef CONFIG_TRACING
+	{ trace_page_fault, xen_trace_page_fault, false },
+#endif
+};
+
+static bool get_trap_addr(unsigned long *addr, unsigned int ist)
+{
+	unsigned int nr;
+	bool ist_okay = false;
+
+	/*
+	 * Replace trap handler addresses by Xen specific ones.
+	 * Check for known traps using IST and whitelist them.
+	 * The debugger ones are the only ones we care about.
+	 * Xen will handle faults like double_fault, * so we should never see
+	 * them.  Warn if there's an unexpected IST-using fault handler.
+	 */
+	for (nr = 0; nr < ARRAY_SIZE(trap_array); nr++)
+		if (*addr == (unsigned long)trap_array[nr].orig) {
+			*addr = (unsigned long)trap_array[nr].xen;
+			ist_okay = trap_array[nr].ist_okay;
+			break;
+		}
+
+	if (WARN_ON(ist != 0 && !ist_okay))
+		return false;
+
+	return true;
+}
+#endif
+
 static int cvt_gate_to_trap(int vector, const gate_desc *val,
 			    struct trap_info *info)
 {
@@ -598,40 +660,8 @@ static int cvt_gate_to_trap(int vector,
 
 	addr = gate_offset(val);
 #ifdef CONFIG_X86_64
-	/*
-	 * Look for known traps using IST, and substitute them
-	 * appropriately.  The debugger ones are the only ones we care
-	 * about.  Xen will handle faults like double_fault,
-	 * so we should never see them.  Warn if
-	 * there's an unexpected IST-using fault handler.
-	 */
-	if (addr == (unsigned long)debug)
-		addr = (unsigned long)xen_debug;
-	else if (addr == (unsigned long)int3)
-		addr = (unsigned long)xen_int3;
-	else if (addr == (unsigned long)stack_segment)
-		addr = (unsigned long)xen_stack_segment;
-	else if (addr == (unsigned long)double_fault) {
-		/* Don't need to handle these */
+	if (!get_trap_addr(&addr, val->bits.ist))
 		return 0;
-#ifdef CONFIG_X86_MCE
-	} else if (addr == (unsigned long)machine_check) {
-		/*
-		 * when xen hypervisor inject vMCE to guest,
-		 * use native mce handler to handle it
-		 */
-		;
-#endif
-	} else if (addr == (unsigned long)nmi)
-		/*
-		 * Use the native version as well.
-		 */
-		;
-	else {
-		/* Some other trap using IST? */
-		if (WARN_ON(val->bits.ist != 0))
-			return 0;
-	}
 #endif	/* CONFIG_X86_64 */
 	info->address = addr;
 
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -123,9 +123,6 @@ static const struct pv_irq_ops xen_irq_o
 
 	.safe_halt = xen_safe_halt,
 	.halt = xen_halt,
-#ifdef CONFIG_X86_64
-	.adjust_exception_frame = xen_adjust_exception_frame,
-#endif
 };
 
 void __init xen_init_irq_ops(void)
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -138,7 +138,6 @@ static inline void __init xen_efi_init(v
 __visible void xen_iret(void);
 __visible void xen_sysret32(void);
 __visible void xen_sysret64(void);
-__visible void xen_adjust_exception_frame(void);
 
 extern int xen_panic_handler_init(void);
 

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Thomas Gleixner]

On Thu, 31 Aug 2017, Stephen Rothwell wrote:
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/include/asm/traps.h
> index b4f322d6c95f,935709829a4e..000000000000
> --- a/arch/x86/include/asm/traps.h
> +++ b/arch/x86/include/asm/traps.h
> @@@ -38,7 -35,34 +35,33 @@@ asmlinkage void machine_check(void)
>   #endif /* CONFIG_X86_MCE */
>   asmlinkage void simd_coprocessor_error(void);
>   
> + #if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
> + asmlinkage void xen_divide_error(void);
> + asmlinkage void xen_xendebug(void);
> + asmlinkage void xen_xenint3(void);
> + asmlinkage void xen_nmi(void);
> + asmlinkage void xen_overflow(void);
> + asmlinkage void xen_bounds(void);
> + asmlinkage void xen_invalid_op(void);
> + asmlinkage void xen_device_not_available(void);
> + asmlinkage void xen_double_fault(void);
> + asmlinkage void xen_coprocessor_segment_overrun(void);
> + asmlinkage void xen_invalid_TSS(void);
> + asmlinkage void xen_segment_not_present(void);
> + asmlinkage void xen_stack_segment(void);
> + asmlinkage void xen_general_protection(void);
> + asmlinkage void xen_page_fault(void);
> + asmlinkage void xen_async_page_fault(void);
> + asmlinkage void xen_spurious_interrupt_bug(void);
> + asmlinkage void xen_coprocessor_error(void);
> + asmlinkage void xen_alignment_check(void);
> + #ifdef CONFIG_X86_MCE
> + asmlinkage void xen_machine_check(void);
> + #endif /* CONFIG_X86_MCE */
> + asmlinkage void xen_simd_coprocessor_error(void);
> + #endif
> + 
>   #ifdef CONFIG_TRACING
>  -asmlinkage void trace_page_fault(void);
>   #define trace_stack_segment stack_segment
>   #define trace_divide_error divide_error
>   #define trace_bounds bounds
> @@@ -53,7 -77,10 +76,11 @@@
>   #define trace_alignment_check alignment_check
>   #define trace_simd_coprocessor_error simd_coprocessor_error
>   #define trace_async_page_fault async_page_fault
>  +#define trace_page_fault page_fault

Hrm. For some reason I missed to remove these defines after getting rid of
the tracing idt.

I'll remove that now in tip and pull in the XEN stuff to see what needs to
be done.

Thanks,

	tglx

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/enlighten_pv.c

between commit:

  64b163fab684 ("x86/idt: Unify gate_struct handling for 32/64-bit kernels")

from the tip tree and commit:

  ad5b8c4ba323 ("xen: get rid of paravirt op adjust_exception_frame")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/xen/enlighten_pv.c
index c76f5ff4d0d7,148527c4e48a..000000000000
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@@ -596,42 -651,10 +658,10 @@@ static int cvt_gate_to_trap(int vector
  
  	info->vector = vector;
  
 -	addr = gate_offset(*val);
 +	addr = gate_offset(val);
  #ifdef CONFIG_X86_64
- 	/*
- 	 * Look for known traps using IST, and substitute them
- 	 * appropriately.  The debugger ones are the only ones we care
- 	 * about.  Xen will handle faults like double_fault,
- 	 * so we should never see them.  Warn if
- 	 * there's an unexpected IST-using fault handler.
- 	 */
- 	if (addr == (unsigned long)debug)
- 		addr = (unsigned long)xen_debug;
- 	else if (addr == (unsigned long)int3)
- 		addr = (unsigned long)xen_int3;
- 	else if (addr == (unsigned long)stack_segment)
- 		addr = (unsigned long)xen_stack_segment;
- 	else if (addr == (unsigned long)double_fault) {
- 		/* Don't need to handle these */
 -	if (!get_trap_addr(&addr, val->ist))
++	if (!get_trap_addr(&addr, val->bits.ist))
  		return 0;
- #ifdef CONFIG_X86_MCE
- 	} else if (addr == (unsigned long)machine_check) {
- 		/*
- 		 * when xen hypervisor inject vMCE to guest,
- 		 * use native mce handler to handle it
- 		 */
- 		;
- #endif
- 	} else if (addr == (unsigned long)nmi)
- 		/*
- 		 * Use the native version as well.
- 		 */
- 		;
- 	else {
- 		/* Some other trap using IST? */
- 		if (WARN_ON(val->bits.ist != 0))
- 			return 0;
- 	}
  #endif	/* CONFIG_X86_64 */
  	info->address = addr;
  

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/include/asm/traps.h

between commit:

  11a7ffb01703 ("x86/traps: Simplify pagefault tracing logic")

from the tip tree and commit:

  ad5b8c4ba323 ("xen: get rid of paravirt op adjust_exception_frame")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/traps.h
index b4f322d6c95f,935709829a4e..000000000000
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@@ -38,7 -35,34 +35,33 @@@ asmlinkage void machine_check(void)
  #endif /* CONFIG_X86_MCE */
  asmlinkage void simd_coprocessor_error(void);
  
+ #if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+ asmlinkage void xen_divide_error(void);
+ asmlinkage void xen_xendebug(void);
+ asmlinkage void xen_xenint3(void);
+ asmlinkage void xen_nmi(void);
+ asmlinkage void xen_overflow(void);
+ asmlinkage void xen_bounds(void);
+ asmlinkage void xen_invalid_op(void);
+ asmlinkage void xen_device_not_available(void);
+ asmlinkage void xen_double_fault(void);
+ asmlinkage void xen_coprocessor_segment_overrun(void);
+ asmlinkage void xen_invalid_TSS(void);
+ asmlinkage void xen_segment_not_present(void);
+ asmlinkage void xen_stack_segment(void);
+ asmlinkage void xen_general_protection(void);
+ asmlinkage void xen_page_fault(void);
+ asmlinkage void xen_async_page_fault(void);
+ asmlinkage void xen_spurious_interrupt_bug(void);
+ asmlinkage void xen_coprocessor_error(void);
+ asmlinkage void xen_alignment_check(void);
+ #ifdef CONFIG_X86_MCE
+ asmlinkage void xen_machine_check(void);
+ #endif /* CONFIG_X86_MCE */
+ asmlinkage void xen_simd_coprocessor_error(void);
+ #endif
+ 
  #ifdef CONFIG_TRACING
 -asmlinkage void trace_page_fault(void);
  #define trace_stack_segment stack_segment
  #define trace_divide_error divide_error
  #define trace_bounds bounds
@@@ -53,7 -77,10 +76,11 @@@
  #define trace_alignment_check alignment_check
  #define trace_simd_coprocessor_error simd_coprocessor_error
  #define trace_async_page_fault async_page_fault
 +#define trace_page_fault page_fault
+ 
+ #if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+ asmlinkage void xen_trace_page_fault(void);
+ #endif
  #endif
  
  dotraplinkage void do_divide_error(struct pt_regs *, long);

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got conflicts in:

  arch/x86/xen/xen-asm.S
  arch/x86/xen/xen-asm_64.S

between commit:

  edcb5cf84f05 ("x86/paravirt/xen: Remove xen_patch()")

from the tip tree and commits:

  ad5b8c4ba323("xen: get rid of paravirt op adjust_exception_frame")
  bd830917233b ("paravirt,xen: remove xen_patch()")

from the xen-tip tree.

I fixed it up (edcb5cf84f05 and bd830917233b ate more or less the same
patch, so I just used the latter version files) and can carry the fix
as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/entry/entry_64.S

between commit:

  UNWIND_HINT_IRET_REGS ("x86/entry/64: Add unwind hint annotations")

from the tip tree and commit:

  ad5b8c4ba323 ("xen: get rid of paravirt op adjust_exception_frame")

from the xen-tip tree.

I fixed it up (see below - though I don't know if a further adjustment
is required) and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/entry/entry_64.S
index ca0b250eefc4,67fefaf21312..000000000000
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@@ -978,15 -891,17 +977,15 @@@ bad_gs
  ENTRY(do_softirq_own_stack)
  	pushq	%rbp
  	mov	%rsp, %rbp
 -	incl	PER_CPU_VAR(irq_count)
 -	cmove	PER_CPU_VAR(irq_stack_ptr), %rsp
 -	push	%rbp				/* frame pointer backlink */
 +	ENTER_IRQ_STACK regs=0 old_rsp=%r11
  	call	__do_softirq
 +	LEAVE_IRQ_STACK regs=0
  	leaveq
 -	decl	PER_CPU_VAR(irq_count)
  	ret
 -END(do_softirq_own_stack)
 +ENDPROC(do_softirq_own_stack)
  
  #ifdef CONFIG_XEN
- idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
+ idtentry hypervisor_callback xen_do_hypervisor_callback has_error_code=0
  
  /*
   * A note on the "critical region" in our callback handler.
@@@ -1053,9 -967,6 +1052,7 @@@ ENTRY(xen_failsafe_callback
  	movq	8(%rsp), %r11
  	addq	$0x30, %rsp
  	pushq	$0				/* RIP */
- 	pushq	%r11
- 	pushq	%rcx
 +	UNWIND_HINT_IRET_REGS offset=8
  	jmp	general_protection
  1:	/* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */
  	movq	(%rsp), %rcx
@@@ -1251,20 -1156,8 +1247,9 @@@ ENTRY(error_exit
  END(error_exit)
  
  /* Runs on exception stack */
+ /* XXX: broken on Xen PV */
  ENTRY(nmi)
 +	UNWIND_HINT_IRET_REGS
- 	/*
- 	 * Fix up the exception frame if we're on Xen.
- 	 * PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most
- 	 * one value to the stack on native, so it may clobber the rdx
- 	 * scratch slot, but it won't clobber any of the important
- 	 * slots past it.
- 	 *
- 	 * Xen is a different story, because the Xen frame itself overlaps
- 	 * the "NMI executing" variable.
- 	 */
- 	PARAVIRT_ADJUST_EXCEPTION_FRAME
- 
  	/*
  	 * We allow breakpoints in NMIs. If a breakpoint occurs, then
  	 * the iretq it performs will take us out of NMI context.

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  drivers/xen/events/events_base.c

between commit:

  ef1c2cc88531 ("xen/events: Add support for effective affinity mask")

from the tip tree and commit:

  c48f64ab4723 ("xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/xen/events/events_base.c
index 2e567d8433b3,813f1e86a599..000000000000
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@@ -1343,12 -1343,8 +1343,12 @@@ static int set_affinity_irq(struct irq_
  			    bool force)
  {
  	unsigned tcpu = cpumask_first_and(dest, cpu_online_mask);
- 	int ret = rebind_irq_to_cpu(data->irq, tcpu);
++	int ret = xen_rebind_evtchn_to_cpu(evtchn_from_irq(data->irq), tcpu);
  
 -	return xen_rebind_evtchn_to_cpu(evtchn_from_irq(data->irq), tcpu);
 +	if (!ret)
 +		irq_data_update_effective_affinity(data, cpumask_of(tcpu));
 +
 +	return ret;
  }
  
  static void enable_dynirq(struct irq_data *data)

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

On Wed, 12 Apr 2017 14:30:21 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
> 
>   arch/x86/xen/enlighten.c
> 
> between commit:
> 
>   687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820 code")
> 
> from the tip tree and commit:
> 
>   ca7b75377014 ("x86/xen: split off enlighten_pvh.c")
> 
> from the xen-tip tree.
> 
> The latter moved the code changed by the former to another file, so I
> have applied the following merge fix patch.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The fix patch now looks like this:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 12 Apr 2017 14:27:23 +1000
Subject: [PATCH] x86/xen: merge fix for arch/x86/xen/enlighten.c code movement

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/xen/enlighten_pvh.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 2bc7d5bb01cf..98ab17673454 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -4,6 +4,7 @@
 
 #include <asm/io_apic.h>
 #include <asm/hypervisor.h>
+#include <asm/e820/api.h>
 
 #include <asm/xen/interface.h>
 #include <asm/xen/hypercall.h>
@@ -37,8 +38,8 @@ static void __init init_pvh_bootparams(void)
 
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
-	set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
+	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
+	set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
 	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
 	if (rc) {
 		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
@@ -46,13 +47,13 @@ static void __init init_pvh_bootparams(void)
 	}
 	pvh_bootparams.e820_entries = memmap.nr_entries;
 
-	if (pvh_bootparams.e820_entries < E820MAX - 1) {
-		pvh_bootparams.e820_map[pvh_bootparams.e820_entries].addr =
+	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
+		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
 			ISA_START_ADDRESS;
-		pvh_bootparams.e820_map[pvh_bootparams.e820_entries].size =
+		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].size =
 			ISA_END_ADDRESS - ISA_START_ADDRESS;
-		pvh_bootparams.e820_map[pvh_bootparams.e820_entries].type =
-			E820_RESERVED;
+		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].type =
+			E820_TYPE_RESERVED;
 		pvh_bootparams.e820_entries++;
 	} else
 		xen_raw_printk("Warning: Can fit ISA range into e820\n");
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/enlighten.c

between commit:

  687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820 code")

from the tip tree and commit:

  ca7b75377014 ("x86/xen: split off enlighten_pvh.c")

from the xen-tip tree.

The latter moved the code changed by the former to another file, so I
have applied the following merge fix patch.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 12 Apr 2017 14:27:23 +1000
Subject: [PATCH] x86/xen: merge fix for arch/x86/xen/enlighten.c code movement

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/xen/enlighten_pvh.c | 27 +++++++++++++--------------
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 331d7696af45..a4272c8620ce 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -4,6 +4,7 @@
 
 #include <asm/io_apic.h>
 #include <asm/hypervisor.h>
+#include <asm/e820/api.h>
 
 #include <asm/xen/interface.h>
 #include <asm/xen/hypercall.h>
@@ -38,34 +39,32 @@ static void __init init_pvh_bootparams(void)
 
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
-	set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
+	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
+	set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
 	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
 	if (rc) {
 		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
 		BUG();
 	}
 
-	if (memmap.nr_entries < E820MAX - 1) {
-		pvh_bootparams.e820_map[memmap.nr_entries].addr =
+	if (memmap.nr_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
+		pvh_bootparams.e820_table[memmap.nr_entries].addr =
 			ISA_START_ADDRESS;
-		pvh_bootparams.e820_map[memmap.nr_entries].size =
+		pvh_bootparams.e820_table[memmap.nr_entries].size =
 			ISA_END_ADDRESS - ISA_START_ADDRESS;
-		pvh_bootparams.e820_map[memmap.nr_entries].type =
-			E820_RESERVED;
+		pvh_bootparams.e820_table[memmap.nr_entries].type =
+			E820_TYPE_RESERVED;
 		memmap.nr_entries++;
 	} else
 		xen_raw_printk("Warning: Can fit ISA range into e820\n");
 
-	sanitize_e820_map(pvh_bootparams.e820_map,
-			  ARRAY_SIZE(pvh_bootparams.e820_map),
-			  &memmap.nr_entries);
-
 	pvh_bootparams.e820_entries = memmap.nr_entries;
 	for (i = 0; i < pvh_bootparams.e820_entries; i++)
-		e820_add_region(pvh_bootparams.e820_map[i].addr,
-				pvh_bootparams.e820_map[i].size,
-				pvh_bootparams.e820_map[i].type);
+		e820__range_add(pvh_bootparams.e820_table[i].addr,
+				pvh_bootparams.e820_table[i].size,
+				pvh_bootparams.e820_table[i].type);
+
+	e820__update_table(e820_table);
 
 	pvh_bootparams.hdr.cmd_line_ptr =
 		pvh_start_info.cmdline_paddr;
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/mmu.c

between commit:

  66441bd3cfdc ("x86/boot/e820: Move asm/e820.h to asm/e820/api.h")

from the tip tree and commit:

  5159dc315db8 ("x86/xen: split off mmu_pv.c")

from the xen-tip tree.

The code changed in the former was moved to a new file by the latter,
so I applied the following merge fix patch.

This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 12 Apr 2017 14:17:58 +1000
Subject: [PATCH] x86/xen: merge fix up for arch/x86/xen/mmu.c code movement

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/xen/mmu_pv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 284d189f40dd..c98bfb9f0248 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -58,7 +58,7 @@
 #include <asm/mmu_context.h>
 #include <asm/setup.h>
 #include <asm/paravirt.h>
-#include <asm/e820.h>
+#include <asm/e820/api.h>
 #include <asm/linkage.h>
 #include <asm/page.h>
 #include <asm/init.h>
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 04/04/17 18:04, Vitaly Kuznetsov wrote:
> Juergen Gross <jgross@suse.com> writes:
> 
>> On 29/03/17 12:06, Vitaly Kuznetsov wrote:
>>> Juergen Gross <jgross@suse.com> writes:
>>>> I'll create another branch for-linus-4.12 based on the tip tree next
>>>> week which will be subject to the pull request for Linus. As soon as
>>>> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
>>>> any longer.
>>>
>>> Please let me know if/when I need to rebase my series. I'll rebase, test
>>> and re-send.
>>
>> Vitaly, I've created the (new) for-linus-4.12 branch on xen/tip. It is
>> based on the x86-mm-for-xen branch of tip/tip containing the 5-level
>> page table patches. Please rebase your patches to this branch.
> 
> Pushed the rebased series to https://github.com/vittyvk/linux.git
> (xen_pv_hvm_split_v4 branch), this includes your fixup patch. No
> functional changes, all tags preserved.
> 
> I smoke tested the rebased patchset by doing PV-and-HVM, PV-only,
> HVM-only builds and booting different guest types, no issues noticed.
> 
> Please let me know if you prefer me to post patches to the mailing list
> instead. Thanks!
> 

Pushed the whole series to xen/tip for-linus-4.12


Juergen

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

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 04/04/17 18:04, Vitaly Kuznetsov wrote:
> Juergen Gross <jgross@suse.com> writes:
> 
>> On 29/03/17 12:06, Vitaly Kuznetsov wrote:
>>> Juergen Gross <jgross@suse.com> writes:
>>>> I'll create another branch for-linus-4.12 based on the tip tree next
>>>> week which will be subject to the pull request for Linus. As soon as
>>>> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
>>>> any longer.
>>>
>>> Please let me know if/when I need to rebase my series. I'll rebase, test
>>> and re-send.
>>
>> Vitaly, I've created the (new) for-linus-4.12 branch on xen/tip. It is
>> based on the x86-mm-for-xen branch of tip/tip containing the 5-level
>> page table patches. Please rebase your patches to this branch.
> 
> Pushed the rebased series to https://github.com/vittyvk/linux.git
> (xen_pv_hvm_split_v4 branch), this includes your fixup patch. No
> functional changes, all tags preserved.
> 
> I smoke tested the rebased patchset by doing PV-and-HVM, PV-only,
> HVM-only builds and booting different guest types, no issues noticed.
> 
> Please let me know if you prefer me to post patches to the mailing list
> instead. Thanks!
> 

I think the git repo is fine.

Thanks for doing the rebase work,


Juergen

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

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Vitaly Kuznetsov]

Juergen Gross <jgross@suse.com> writes:

> On 29/03/17 12:06, Vitaly Kuznetsov wrote:
>> Juergen Gross <jgross@suse.com> writes:
>>> I'll create another branch for-linus-4.12 based on the tip tree next
>>> week which will be subject to the pull request for Linus. As soon as
>>> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
>>> any longer.
>> 
>> Please let me know if/when I need to rebase my series. I'll rebase, test
>> and re-send.
>
> Vitaly, I've created the (new) for-linus-4.12 branch on xen/tip. It is
> based on the x86-mm-for-xen branch of tip/tip containing the 5-level
> page table patches. Please rebase your patches to this branch.

Pushed the rebased series to https://github.com/vittyvk/linux.git
(xen_pv_hvm_split_v4 branch), this includes your fixup patch. No
functional changes, all tags preserved.

I smoke tested the rebased patchset by doing PV-and-HVM, PV-only,
HVM-only builds and booting different guest types, no issues noticed.

Please let me know if you prefer me to post patches to the mailing list
instead. Thanks!

-- 
  Vitaly

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

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 29/03/17 12:06, Vitaly Kuznetsov wrote:
> Juergen Gross <jgross@suse.com> writes:
>> I'll create another branch for-linus-4.12 based on the tip tree next
>> week which will be subject to the pull request for Linus. As soon as
>> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
>> any longer.
> 
> Please let me know if/when I need to rebase my series. I'll rebase, test
> and re-send.

Vitaly, I've created the (new) for-linus-4.12 branch on xen/tip. It is
based on the x86-mm-for-xen branch of tip/tip containing the 5-level
page table patches. Please rebase your patches to this branch.


Juergen

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

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 03/04/17 16:38, Ingo Molnar wrote:
> 
> * Juergen Gross <jgross@suse.com> wrote:
> 
>>> So my suggestion would be: could you delay 75cd32d6093e for a week, and then 
>>> merge it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the 
>>> first day of the merge window so there shouldn't be any ordering problems.
>>
>> Okay, that's rather easy to do.
>>
>> Boris, I renamed the current Xen for-linus-4.12 branch for easy development of 
>> other Xen patches to for-linus-4.12-pre.
>>
>> I'll create another branch for-linus-4.12 based on the tip tree next week which 
>> will be subject to the pull request for Linus. As soon as for-linus-4.12 is 
>> ready the for-linus-4.12-pre branch shouldn't be used any longer.
> 
> I've created a tip:x86-mm-for-xen branch with the following head:
> 
>   7f75540ff2ca ("Merge tag 'v4.11-rc5' into x86/mm, to refresh the branch")
> 
> ... which should be a reasonable base that includes a working version of the 
> 5-level pagetable changes.

Thanks,


Juergen


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

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Ingo Molnar]

* Juergen Gross <jgross@suse.com> wrote:

> > So my suggestion would be: could you delay 75cd32d6093e for a week, and then 
> > merge it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the 
> > first day of the merge window so there shouldn't be any ordering problems.
> 
> Okay, that's rather easy to do.
> 
> Boris, I renamed the current Xen for-linus-4.12 branch for easy development of 
> other Xen patches to for-linus-4.12-pre.
> 
> I'll create another branch for-linus-4.12 based on the tip tree next week which 
> will be subject to the pull request for Linus. As soon as for-linus-4.12 is 
> ready the for-linus-4.12-pre branch shouldn't be used any longer.

I've created a tip:x86-mm-for-xen branch with the following head:

  7f75540ff2ca ("Merge tag 'v4.11-rc5' into x86/mm, to refresh the branch")

... which should be a reasonable base that includes a working version of the 
5-level pagetable changes.

Thanks,

	Ingo

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi Juergen,

On Wed, 29 Mar 2017 11:54:57 +0200 Juergen Gross <jgross@suse.com> wrote:
>
> Stephen, I have rewound the linux-next branch of xen-tip to its previous
> position. You can re-enable xen-tip.

Thanks, it should be all good tomorrow.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Ingo Molnar]

* Juergen Gross <jgross@suse.com> wrote:

> On 29/03/17 10:59, Ingo Molnar wrote:
> > 
> > * Juergen Gross <jgross@suse.com> wrote:
> > 
> >> On 29/03/17 05:35, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Today's linux-next merge of the xen-tip tree got a conflict in:
> >>>
> >>>   arch/x86/xen/enlighten.c
> >>>
> >>> between commits:
> >>>
> >>>   6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
> >>>   69218e47994d ("x86: Remap GDT tables in the fixmap section")
> >>>   b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
> >>>
> >>> from the tip tree and commits:
> >>>
> >>>   75cd32d6093e ("x86/xen: split off enlighten_pv.c")
> >>>
> >>> from the xen-tip tree.
> >>>
> >>> I dropped the xen-tip tree for today (see other conflict reports),
> >>> please get together and sort these out, thanks.
> 
> Stephen, I have rewound the linux-next branch of xen-tip to its previous
> position. You can re-enable xen-tip.

Thank you!

	Ingo

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Vitaly Kuznetsov]

Juergen Gross <jgross@suse.com> writes:

> On 29/03/17 10:59, Ingo Molnar wrote:
>> 
>> * Juergen Gross <jgross@suse.com> wrote:
>> 
>>> On 29/03/17 05:35, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Today's linux-next merge of the xen-tip tree got a conflict in:
>>>>
>>>>   arch/x86/xen/enlighten.c
>>>>
>>>> between commits:
>>>>
>>>>   6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
>>>>   69218e47994d ("x86: Remap GDT tables in the fixmap section")
>>>>   b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
>>>>
>>>> from the tip tree and commits:
>>>>
>>>>   75cd32d6093e ("x86/xen: split off enlighten_pv.c")
>>>>
>>>> from the xen-tip tree.
>>>>
>>>> I dropped the xen-tip tree for today (see other conflict reports),
>>>> please get together and sort these out, thanks.
>>>>
>>>
>>> Hmm, seems to be a rather bad timing for the series of Vitaly.
>>>
>>> What is the best way to resolve those conflicts? A rebase of Vitaly's
>>> patches seems to be required in any case.
>>>
>>> Should I rebase the Xen tree on current tip? This seems to be rather
>>> easy, but I think this will work only if I can be sure the current tip
>>> tree contents will all be merged by Linus before the Xen tree.
>> 
>> That's certainly very likely, -tip trees all go in very early in the merge window.
>> 
>>> I could try to cherry pick the patches from tip where Vitaly's patches
>>> have conflicts with, but I think this could lead to a lot of patches
>>> to take.
>> 
>> Nor is it desirable as a workflow.
>> 
>> I'd suggest the following: in about a week I can guarantee a working tip:x86/mm 
>> base with most of the 5-level paging patches applied that you could base Xen 
>> patches on.
>> 
>> Unfortunately, right now there's at least one regression with those changes that 
>> needs to be properly fixed before it's a suitable base tree. The fix already 
>> exists, it just needs to be tested and the whole tree needs to cook for a few days 
>> to be dependable for Xen as a base.
>> 
>>> Or we could delay Vitaly's series until tip has been merged, but this
>>> will either delay some other Xen patches depending on (or conflicting
>>> with) Vitaly's patches or would make the rebase for Vitaly more
>>> difficult.
>> 
>> So my suggestion would be: could you delay 75cd32d6093e for a week, and then merge 
>> it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the first day 
>> of the merge window so there shouldn't be any ordering problems.
>
> Okay, that's rather easy to do.
>
> Boris, I renamed the current Xen for-linus-4.12 branch for easy
> development of other Xen patches to for-linus-4.12-pre.
>
> I'll create another branch for-linus-4.12 based on the tip tree next
> week which will be subject to the pull request for Linus. As soon as
> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
> any longer.

Please let me know if/when I need to rebase my series. I'll rebase, test
and re-send.

Thanks!

-- 
  Vitaly

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 29/03/17 10:59, Ingo Molnar wrote:
> 
> * Juergen Gross <jgross@suse.com> wrote:
> 
>> On 29/03/17 05:35, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the xen-tip tree got a conflict in:
>>>
>>>   arch/x86/xen/enlighten.c
>>>
>>> between commits:
>>>
>>>   6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
>>>   69218e47994d ("x86: Remap GDT tables in the fixmap section")
>>>   b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
>>>
>>> from the tip tree and commits:
>>>
>>>   75cd32d6093e ("x86/xen: split off enlighten_pv.c")
>>>
>>> from the xen-tip tree.
>>>
>>> I dropped the xen-tip tree for today (see other conflict reports),
>>> please get together and sort these out, thanks.

Stephen, I have rewound the linux-next branch of xen-tip to its previous
position. You can re-enable xen-tip.


Juergen

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 29/03/17 10:59, Ingo Molnar wrote:
> 
> * Juergen Gross <jgross@suse.com> wrote:
> 
>> On 29/03/17 05:35, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the xen-tip tree got a conflict in:
>>>
>>>   arch/x86/xen/enlighten.c
>>>
>>> between commits:
>>>
>>>   6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
>>>   69218e47994d ("x86: Remap GDT tables in the fixmap section")
>>>   b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
>>>
>>> from the tip tree and commits:
>>>
>>>   75cd32d6093e ("x86/xen: split off enlighten_pv.c")
>>>
>>> from the xen-tip tree.
>>>
>>> I dropped the xen-tip tree for today (see other conflict reports),
>>> please get together and sort these out, thanks.
>>>
>>
>> Hmm, seems to be a rather bad timing for the series of Vitaly.
>>
>> What is the best way to resolve those conflicts? A rebase of Vitaly's
>> patches seems to be required in any case.
>>
>> Should I rebase the Xen tree on current tip? This seems to be rather
>> easy, but I think this will work only if I can be sure the current tip
>> tree contents will all be merged by Linus before the Xen tree.
> 
> That's certainly very likely, -tip trees all go in very early in the merge window.
> 
>> I could try to cherry pick the patches from tip where Vitaly's patches
>> have conflicts with, but I think this could lead to a lot of patches
>> to take.
> 
> Nor is it desirable as a workflow.
> 
> I'd suggest the following: in about a week I can guarantee a working tip:x86/mm 
> base with most of the 5-level paging patches applied that you could base Xen 
> patches on.
> 
> Unfortunately, right now there's at least one regression with those changes that 
> needs to be properly fixed before it's a suitable base tree. The fix already 
> exists, it just needs to be tested and the whole tree needs to cook for a few days 
> to be dependable for Xen as a base.
> 
>> Or we could delay Vitaly's series until tip has been merged, but this
>> will either delay some other Xen patches depending on (or conflicting
>> with) Vitaly's patches or would make the rebase for Vitaly more
>> difficult.
> 
> So my suggestion would be: could you delay 75cd32d6093e for a week, and then merge 
> it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the first day 
> of the merge window so there shouldn't be any ordering problems.

Okay, that's rather easy to do.

Boris, I renamed the current Xen for-linus-4.12 branch for easy
development of other Xen patches to for-linus-4.12-pre.

I'll create another branch for-linus-4.12 based on the tip tree next
week which will be subject to the pull request for Linus. As soon as
for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
any longer.


Juergen

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Ingo Molnar]

* Juergen Gross <jgross@suse.com> wrote:

> On 29/03/17 05:35, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the xen-tip tree got a conflict in:
> > 
> >   arch/x86/xen/enlighten.c
> > 
> > between commits:
> > 
> >   6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
> >   69218e47994d ("x86: Remap GDT tables in the fixmap section")
> >   b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
> > 
> > from the tip tree and commits:
> > 
> >   75cd32d6093e ("x86/xen: split off enlighten_pv.c")
> > 
> > from the xen-tip tree.
> > 
> > I dropped the xen-tip tree for today (see other conflict reports),
> > please get together and sort these out, thanks.
> > 
> 
> Hmm, seems to be a rather bad timing for the series of Vitaly.
> 
> What is the best way to resolve those conflicts? A rebase of Vitaly's
> patches seems to be required in any case.
> 
> Should I rebase the Xen tree on current tip? This seems to be rather
> easy, but I think this will work only if I can be sure the current tip
> tree contents will all be merged by Linus before the Xen tree.

That's certainly very likely, -tip trees all go in very early in the merge window.

> I could try to cherry pick the patches from tip where Vitaly's patches
> have conflicts with, but I think this could lead to a lot of patches
> to take.

Nor is it desirable as a workflow.

I'd suggest the following: in about a week I can guarantee a working tip:x86/mm 
base with most of the 5-level paging patches applied that you could base Xen 
patches on.

Unfortunately, right now there's at least one regression with those changes that 
needs to be properly fixed before it's a suitable base tree. The fix already 
exists, it just needs to be tested and the whole tree needs to cook for a few days 
to be dependable for Xen as a base.

> Or we could delay Vitaly's series until tip has been merged, but this
> will either delay some other Xen patches depending on (or conflicting
> with) Vitaly's patches or would make the rebase for Vitaly more
> difficult.

So my suggestion would be: could you delay 75cd32d6093e for a week, and then merge 
it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the first day 
of the merge window so there shouldn't be any ordering problems.

Thanks,

	Ingo

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 29/03/17 05:35, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xen-tip tree got a conflict in:
> 
>   arch/x86/xen/enlighten.c
> 
> between commits:
> 
>   6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
>   69218e47994d ("x86: Remap GDT tables in the fixmap section")
>   b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
> 
> from the tip tree and commits:
> 
>   75cd32d6093e ("x86/xen: split off enlighten_pv.c")
> 
> from the xen-tip tree.
> 
> I dropped the xen-tip tree for today (see other conflict reports),
> please get together and sort these out, thanks.
> 

Hmm, seems to be a rather bad timing for the series of Vitaly.

What is the best way to resolve those conflicts? A rebase of Vitaly's
patches seems to be required in any case.

Should I rebase the Xen tree on current tip? This seems to be rather
easy, but I think this will work only if I can be sure the current tip
tree contents will all be merged by Linus before the Xen tree.

I could try to cherry pick the patches from tip where Vitaly's patches
have conflicts with, but I think this could lead to a lot of patches
to take.

Or we could delay Vitaly's series until tip has been merged, but this
will either delay some other Xen patches depending on (or conflicting
with) Vitaly's patches or would make the rebase for Vitaly more
difficult.

Thoughts?


Juergen

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

On Wed, 29 Mar 2017 14:36:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
> 
>   arch/x86/xen/mmu.c
> 
> between commits:
> 
>   69218e47994d ("x86: Remap GDT tables in the fixmap section")
>   907cd4390290 ("x86/xen: Change __xen_pgd_walk() and xen_cleanmfnmap() to support p4d")
>   f2a6a7050109 ("x86: Convert the rest of the code to support p4d_t")
> 
> from the tip tree and commit:
> 
>   48a09cbf855e ("x86/xen: split off mmu_pv.c")
> 
> from the xen-tip tree.
> 
> I dropped the xen-tip tree for today, please get together and sort
> these conflicts out.

There were conflicts in arch/x86/xen/smp.c as well.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/mmu.c

between commits:

  69218e47994d ("x86: Remap GDT tables in the fixmap section")
  907cd4390290 ("x86/xen: Change __xen_pgd_walk() and xen_cleanmfnmap() to support p4d")
  f2a6a7050109 ("x86: Convert the rest of the code to support p4d_t")

from the tip tree and commit:

  48a09cbf855e ("x86/xen: split off mmu_pv.c")

from the xen-tip tree.

I dropped the xen-tip tree for today, please get together and sort
these conflicts out.
-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/enlighten.c

between commits:

  6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
  69218e47994d ("x86: Remap GDT tables in the fixmap section")
  b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")

from the tip tree and commits:

  75cd32d6093e ("x86/xen: split off enlighten_pv.c")

from the xen-tip tree.

I dropped the xen-tip tree for today (see other conflict reports),
please get together and sort these out, thanks.
-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  include/linux/cpuhotplug.h

between commit:

  dfc616d8b3df ("cpuidle/coupled: Convert to hotplug state machine")
  68e694dcef24 ("powerpc/powermac: Convert to hotplug state machine")
  da3ed6519b19 ("powerpc/mmu nohash: Convert to hotplug state machine")

from the tip tree and commits:

  4d737042d6c4 ("xen/x86: Convert to hotplug state machine")
  c8761e2016aa ("xen/events: Convert to hotplug state machine")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/cpuhotplug.h
index a8ffc405f915,5f603166831c..000000000000
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@@ -36,20 -20,11 +36,22 @@@ enum cpuhp_state 
  	CPUHP_PROFILE_PREPARE,
  	CPUHP_X2APIC_PREPARE,
  	CPUHP_SMPCFD_PREPARE,
 +	CPUHP_RELAY_PREPARE,
 +	CPUHP_SLAB_PREPARE,
 +	CPUHP_MD_RAID5_PREPARE,
  	CPUHP_RCUTREE_PREP,
 +	CPUHP_CPUIDLE_COUPLED_PREPARE,
 +	CPUHP_POWERPC_PMAC_PREPARE,
 +	CPUHP_POWERPC_MMU_CTX_PREPARE,
+ 	CPUHP_XEN_PREPARE,
+ 	CPUHP_XEN_EVTCHN_PREPARE,
  	CPUHP_NOTIFY_PREPARE,
 +	CPUHP_ARM_SHMOBILE_SCU_PREPARE,
 +	CPUHP_SH_SH3X_PREPARE,
 +	CPUHP_BLK_MQ_PREPARE,
  	CPUHP_TIMERS_DEAD,
 +	CPUHP_NOTF_ERR_INJ_PREPARE,
 +	CPUHP_MIPS_SOC_PREPARE,
  	CPUHP_BRINGUP_CPU,
  	CPUHP_AP_IDLE_DEAD,
  	CPUHP_AP_OFFLINE,

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Boris Ostrovsky]

On 07/26/2016 12:01 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
>
>   arch/x86/xen/enlighten.c
>
> between commit:
>
>   4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()")
>
> from the tip tree and commit:
>
>   88e957d6e47f ("xen: introduce xen_vcpu_id mapping")
>
> from the xen-tip tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.
> This is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>

Thank you Stephen. Both this and arch/x86/xen/smp.c merges (from another
message) look good.

-boris

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

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/smp.c

between commit:

  4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()")

from the tip tree and commit:

  ad5475f9faf5 ("x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op")

from the xen-tip tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/xen/smp.c
index 09d5cc062dbe,0b4d04c8ab4d..000000000000
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@@ -486,7 -495,11 +493,7 @@@ static int xen_cpu_up(unsigned int cpu
  
  	xen_pmu_init(cpu);
  
- 	rc = HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
 -	rc = xen_smp_intr_init(cpu);
 -	if (rc)
 -		return rc;
 -
+ 	rc = HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL);
  	BUG_ON(rc);
  
  	while (cpu_report_state(cpu) != CPU_ONLINE)

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/enlighten.c

between commit:

  4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()")

from the tip tree and commit:

  88e957d6e47f ("xen: introduce xen_vcpu_id mapping")

from the xen-tip tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/xen/enlighten.c
index dc96f939af88,85ef4c0442e0..000000000000
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@@ -1803,49 -1823,21 +1824,53 @@@ static void __init init_hvm_pv_info(voi
  	xen_domain_type = XEN_HVM_DOMAIN;
  }
  
 -static int xen_hvm_cpu_notify(struct notifier_block *self, unsigned long action,
 -			      void *hcpu)
 +static int xen_cpu_notify(struct notifier_block *self, unsigned long action,
 +			  void *hcpu)
  {
  	int cpu = (long)hcpu;
 +	int rc;
 +
  	switch (action) {
  	case CPU_UP_PREPARE:
 -		if (cpu_acpi_id(cpu) != U32_MAX)
 -			per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
 -		else
 -			per_cpu(xen_vcpu_id, cpu) = cpu;
 -		xen_vcpu_setup(cpu);
 -		if (xen_have_vector_callback) {
 -			if (xen_feature(XENFEAT_hvm_safe_pvclock))
 -				xen_setup_timer(cpu);
 +		if (xen_hvm_domain()) {
 +			/*
 +			 * This can happen if CPU was offlined earlier and
 +			 * offlining timed out in common_cpu_die().
 +			 */
 +			if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
 +				xen_smp_intr_free(cpu);
 +				xen_uninit_lock_cpu(cpu);
 +			}
 +
++			if (cpu_acpi_id(cpu) != U32_MAX)
++				per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
++			else
++				per_cpu(xen_vcpu_id, cpu) = cpu;
 +			xen_vcpu_setup(cpu);
  		}
 +
 +		if (xen_pv_domain() ||
 +		    (xen_have_vector_callback &&
 +		     xen_feature(XENFEAT_hvm_safe_pvclock)))
 +			xen_setup_timer(cpu);
 +
 +		rc = xen_smp_intr_init(cpu);
 +		if (rc) {
 +			WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
 +			     cpu, rc);
 +			return NOTIFY_BAD;
 +		}
 +
 +		break;
 +	case CPU_ONLINE:
 +		xen_init_lock_cpu(cpu);
 +		break;
 +	case CPU_UP_CANCELED:
 +		xen_smp_intr_free(cpu);
 +		if (xen_pv_domain() ||
 +		    (xen_have_vector_callback &&
 +		     xen_feature(XENFEAT_hvm_safe_pvclock)))
 +			xen_teardown_timer(cpu);
  		break;
  	default:
  		break;

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/arm/xen/enlighten.c

between commit:

  4761adb6f490 ("arm/xen: Convert to hotplug state machine")

from the tip tree and commit:

  ecb23dc6f2ef ("xen: add steal_clock support on x86")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/xen/enlighten.c
index d822e2313950,2f4c3aa540eb..000000000000
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@@ -334,8 -414,12 +397,8 @@@ static int __init xen_guest_init(void
  		return -EINVAL;
  	}
  
- 	pv_time_ops.steal_clock = xen_stolen_accounting;
- 	static_key_slow_inc(&paravirt_steal_enabled);
 -	xen_percpu_init();
 -
 -	register_cpu_notifier(&xen_cpu_notifier);
 -
+ 	xen_time_setup_guest();
+ 
  	if (xen_initial_domain())
  		pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
  

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  drivers/xen/efi.c

between commit:

  0ec7ae928a9c ("efi: Remove unnecessary (and buggy) .memmap initialization from the Xen EFI driver")

from the tip tree and commit:

  acb2c923a860 ("XEN: EFI: Move x86 specific codes to architecture directory")

from the xen-tip tree.

I fixed it up (I used the xen-tip version of this file and added the below
merge fix patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 May 2016 14:47:32 +1000
Subject: [PATCH] xen: efi: merge fix patch

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/xen/efi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 86527f1d1427..3be012115853 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -83,7 +83,6 @@ static const struct efi efi_xen __initconst = {
 	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
 	.reset_system             = NULL, /* Functionality provided by Xen. */
 	.set_virtual_address_map  = NULL, /* Not used under Xen. */
-	.memmap                   = NULL, /* Not used under Xen. */
 	.flags			  = 0     /* Initialized later. */
 };
 
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, Aug 12, 2015 at 02:44:52PM -0400, Boris Ostrovsky wrote:
> > On 08/12/2015 02:36 PM, Peter Zijlstra wrote:
> > >On Wed, Aug 12, 2015 at 11:26:41AM -0700, H. Peter Anvin wrote:
> > >>One option might be to do the addition in assembly, i.e.:
> > >>
> > >>"i" (key), "i" (index)
> > >>
> > >>... and put the addition into the assembly source.
> > >Like so? Seems to build on gcc-4.6.
> > 
> > Yes, this builds on 4.4.4. as well.
> 
> Thanks, Ingo / Hpa, can you make the below patch appear in the right tip
> branch?

Applied, it will show up as the following commit:

  d420acd816c0 ("jump_label/x86: Work around asm build bug on older/backported GCCs")

Thanks,

	Ingo

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Peter Zijlstra]

On Wed, Aug 12, 2015 at 02:44:52PM -0400, Boris Ostrovsky wrote:
> On 08/12/2015 02:36 PM, Peter Zijlstra wrote:
> >On Wed, Aug 12, 2015 at 11:26:41AM -0700, H. Peter Anvin wrote:
> >>One option might be to do the addition in assembly, i.e.:
> >>
> >>"i" (key), "i" (index)
> >>
> >>... and put the addition into the assembly source.
> >Like so? Seems to build on gcc-4.6.
> 
> Yes, this builds on 4.4.4. as well.

Thanks, Ingo / Hpa, can you make the below patch appear in the right tip
branch?

---
Subject: jump_label, x86: Fix asm for older GCCs
From: Peter Zijlstra <peterz@infradead.org>
Date: Wed Aug 12 20:58:48 CEST 2015

Boris reported that: gcc version 4.4.4 20100503 (Red Hat 4.4.4-2)
fails to build. The problem appears that even though @key and @branch
are compile time constants it doesn't see: &((char *)key)[branch]
as an immediate. More recent GCCs don't appear to have this problem.

In particular, Red Hat backported the asm goto feature into 4.4,
'normal' 4.4 compilers will not have this feature and thus not run
into this asm.

The solution is to supply both values to the asm as immediates and do
the addition in asm.

Suggested-by: "H. Peter Anvin" <hpa@zytor.com>
Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 arch/x86/include/asm/jump_label.h |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -22,9 +22,9 @@ static __always_inline bool arch_static_
 		".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
 		".pushsection __jump_table,  \"aw\" \n\t"
 		_ASM_ALIGN "\n\t"
-		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
+		_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
 		".popsection \n\t"
-		: :  "i" (&((char *)key)[branch]) : : l_yes);
+		: :  "i" (key), "i" (branch) : : l_yes);
 
 	return false;
 l_yes:
@@ -38,9 +38,9 @@ static __always_inline bool arch_static_
 		"2:\n\t"
 		".pushsection __jump_table,  \"aw\" \n\t"
 		_ASM_ALIGN "\n\t"
-		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
+		_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
 		".popsection \n\t"
-		: :  "i" (&((char *)key)[branch]) : : l_yes);
+		: :  "i" (key), "i" (branch) : : l_yes);
 
 	return false;
 l_yes:

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Boris Ostrovsky]

On 08/12/2015 02:36 PM, Peter Zijlstra wrote:
> On Wed, Aug 12, 2015 at 11:26:41AM -0700, H. Peter Anvin wrote:
>> One option might be to do the addition in assembly, i.e.:
>>
>> "i" (key), "i" (index)
>>
>> ... and put the addition into the assembly source.
> Like so? Seems to build on gcc-4.6.

Yes, this builds on 4.4.4. as well.

-boris

>
> ---
>   arch/x86/include/asm/jump_label.h | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/jump_label.h b/arch/x86/include/asm/jump_label.h
> index 28d7a857f9d1..5daeca3d0f9e 100644
> --- a/arch/x86/include/asm/jump_label.h
> +++ b/arch/x86/include/asm/jump_label.h
> @@ -22,9 +22,9 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
>   		".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
>   		".pushsection __jump_table,  \"aw\" \n\t"
>   		_ASM_ALIGN "\n\t"
> -		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> +		_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>   		".popsection \n\t"
> -		: :  "i" (&((char *)key)[branch]) : : l_yes);
> +		: :  "i" (key), "i" (branch) : : l_yes);
>   
>   	return false;
>   l_yes:
> @@ -38,9 +38,9 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool
>   		"2:\n\t"
>   		".pushsection __jump_table,  \"aw\" \n\t"
>   		_ASM_ALIGN "\n\t"
> -		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> +		_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>   		".popsection \n\t"
> -		: :  "i" (&((char *)key)[branch]) : : l_yes);
> +		: :  "i" (key), "i" (branch) : : l_yes);
>   
>   	return false;
>   l_yes:

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Peter Zijlstra]

On Wed, Aug 12, 2015 at 11:26:41AM -0700, H. Peter Anvin wrote:
> One option might be to do the addition in assembly, i.e.:
> 
> "i" (key), "i" (index)
> 
> ... and put the addition into the assembly source.

Like so? Seems to build on gcc-4.6.

---
 arch/x86/include/asm/jump_label.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/jump_label.h b/arch/x86/include/asm/jump_label.h
index 28d7a857f9d1..5daeca3d0f9e 100644
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -22,9 +22,9 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
 		".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
 		".pushsection __jump_table,  \"aw\" \n\t"
 		_ASM_ALIGN "\n\t"
-		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
+		_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
 		".popsection \n\t"
-		: :  "i" (&((char *)key)[branch]) : : l_yes);
+		: :  "i" (key), "i" (branch) : : l_yes);
 
 	return false;
 l_yes:
@@ -38,9 +38,9 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool
 		"2:\n\t"
 		".pushsection __jump_table,  \"aw\" \n\t"
 		_ASM_ALIGN "\n\t"
-		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
+		_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
 		".popsection \n\t"
-		: :  "i" (&((char *)key)[branch]) : : l_yes);
+		: :  "i" (key), "i" (branch) : : l_yes);
 
 	return false;
 l_yes:

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Boris Ostrovsky]

On 08/12/2015 02:26 PM, Andy Lutomirski wrote:
> On Wed, Aug 12, 2015 at 11:17 AM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> On 08/12/2015 01:46 PM, Peter Zijlstra wrote:
>>> On Wed, Aug 12, 2015 at 07:21:05PM +0200, Peter Zijlstra wrote:
>>>> On Wed, Aug 12, 2015 at 09:27:38AM -0400, Boris Ostrovsky wrote:
>>>>
>>>>> Incidentally, 11276d53 ("locking/static_keys: Add a new static_key
>>>>> interface") breaks old-ish compilers (gcc version 4.4.4 20100503 (Red
>>>>> Hat
>>>>> 4.4.4-2) (GCC)):
>>>>>
>>>>>
>>>>>
>>>>>     CC      arch/x86/kernel/nmi.o
>>>>> In file included from
>>>>> /home/build/linux-boris/include/linux/jump_label.h:109,
>>>>>                    from
>>>>> /home/build/linux-boris/arch/x86/include/asm/spinlock.h:5,
>>>>>                    from
>>>>> /home/build/linux-boris/include/linux/spinlock.h:88,
>>>>>                    from /home/build/linux-boris/arch/x86/kernel/nmi.c:14:
>>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h: In function
>>>>> ‘nmi_handle’:
>>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: warning:
>>>>> asm
>>>>> operand 0 probably doesn’t match constraints
>>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: error:
>>>>> impossible constraint in ‘asm’
>>>>> make[3]: *** [arch/x86/kernel/nmi.o] Error 1
>>>>> make[2]: *** [arch/x86/kernel] Error 2
>>>>> make[1]: *** [arch/x86] Error 2
>>>> Ugh bugger.
>>>>
>>>> I bet its that: &((char *)key)[branch] business, an earlier variant
>>>> thereof tripped up more recent GCCs too.
>>>>
>>>> So its an __always_inline function, and both argument are always compile
>>>> time constants, @key is the address of an object in static storage (a
>>>> global) and @branch is a simple 0/1 at the call site.
>>>>
>>>> Now we wish to compute (unsigned long)key + branch at compile/link time
>>>> to feed to the assembler as an immediate, which should be possible,
>>>> given its all 'constants'.
>>>>
>>>> It just appears GCC is having a hard time with this.
>>>>
>>>> Let me see if I have a sufficiently old GCC around to play with.
>>> Could you feed the below to your compiler? Its a bit cumbersome, but
>>> its the next best I could come up with...
>>
>> No, it produces the same error. This is Fedora 13, btw, uses gcc 4.4.4.
> Is the problem just that it's being misdetected as supporting asm
> goto?  What does gcc -E say?

static inline __attribute__((no_instrument_function)) 
__attribute__((always_inline)) bool arch_static_branch(struct static_key 
*key, bool branch)
{
  do { asm goto("1:" ".byte " "0x0f,0x1f,0x44,0x00,0" "\n\t" 
".pushsection __jump_table,  \"aw\" \n\t" " " ".balign 8" " " "\n\t" " " 
".quad" " " "1b, %l[l_yes], %c0 \n\t" ".popsection \n\t" : : "i" 
(&((char *)key)[branch]) : : l_yes); asm (""); } while (0)

return false;
l_yes:
  return true;
}

-boris

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[H. Peter Anvin]

One option might be to do the addition in assembly, i.e.:

"i" (key), "i" (index)

... and put the addition into the assembly source.

On August 12, 2015 11:17:17 AM PDT, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>On 08/12/2015 01:46 PM, Peter Zijlstra wrote:
>> On Wed, Aug 12, 2015 at 07:21:05PM +0200, Peter Zijlstra wrote:
>>> On Wed, Aug 12, 2015 at 09:27:38AM -0400, Boris Ostrovsky wrote:
>>>
>>>> Incidentally, 11276d53 ("locking/static_keys: Add a new static_key
>>>> interface") breaks old-ish compilers (gcc version 4.4.4 20100503
>(Red Hat
>>>> 4.4.4-2) (GCC)):
>>>>
>>>>
>>>>
>>>>    CC      arch/x86/kernel/nmi.o
>>>> In file included from
>>>> /home/build/linux-boris/include/linux/jump_label.h:109,
>>>>                   from
>>>> /home/build/linux-boris/arch/x86/include/asm/spinlock.h:5,
>>>>                   from
>/home/build/linux-boris/include/linux/spinlock.h:88,
>>>>                   from
>/home/build/linux-boris/arch/x86/kernel/nmi.c:14:
>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h: In
>function
>>>> ‘nmi_handle’:
>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21:
>warning: asm
>>>> operand 0 probably doesn’t match constraints
>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21:
>error:
>>>> impossible constraint in ‘asm’
>>>> make[3]: *** [arch/x86/kernel/nmi.o] Error 1
>>>> make[2]: *** [arch/x86/kernel] Error 2
>>>> make[1]: *** [arch/x86] Error 2
>>> Ugh bugger.
>>>
>>> I bet its that: &((char *)key)[branch] business, an earlier variant
>>> thereof tripped up more recent GCCs too.
>>>
>>> So its an __always_inline function, and both argument are always
>compile
>>> time constants, @key is the address of an object in static storage
>(a
>>> global) and @branch is a simple 0/1 at the call site.
>>>
>>> Now we wish to compute (unsigned long)key + branch at compile/link
>time
>>> to feed to the assembler as an immediate, which should be possible,
>>> given its all 'constants'.
>>>
>>> It just appears GCC is having a hard time with this.
>>>
>>> Let me see if I have a sufficiently old GCC around to play with.
>> Could you feed the below to your compiler? Its a bit cumbersome, but
>> its the next best I could come up with...
>
>No, it produces the same error. This is Fedora 13, btw, uses gcc 4.4.4.
>
>-boris
>
>
>>
>> ---
>>   arch/x86/include/asm/jump_label.h | 56
>++++++++++++++++++++++++++++-----------
>>   1 file changed, 41 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/jump_label.h
>b/arch/x86/include/asm/jump_label.h
>> index 28d7a857f9d1..76c769ae4200 100644
>> --- a/arch/x86/include/asm/jump_label.h
>> +++ b/arch/x86/include/asm/jump_label.h
>> @@ -16,15 +16,30 @@
>>   # define STATIC_KEY_INIT_NOP GENERIC_NOP5_ATOMIC
>>   #endif
>>   
>> +struct foo {
>> +	u8 zero;
>> +	u8 one;
>> +};
>> +
>>   static __always_inline bool arch_static_branch(struct static_key
>*key, bool branch)
>>   {
>> -	asm_volatile_goto("1:"
>> -		".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
>> -		".pushsection __jump_table,  \"aw\" \n\t"
>> -		_ASM_ALIGN "\n\t"
>> -		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
>> -		".popsection \n\t"
>> -		: :  "i" (&((char *)key)[branch]) : : l_yes);
>> +	if (!branch) {
>> +		asm_volatile_goto("1:"
>> +				".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
>> +				".pushsection __jump_table,  \"aw\" \n\t"
>> +				_ASM_ALIGN "\n\t"
>> +				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
>> +				".popsection \n\t"
>> +				: :  "i" (&((struct foo *)key)->zero) : : l_yes);
>> +	} else {
>> +		asm_volatile_goto("1:"
>> +				".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
>> +				".pushsection __jump_table,  \"aw\" \n\t"
>> +				_ASM_ALIGN "\n\t"
>> +				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
>> +				".popsection \n\t"
>> +				: :  "i" (&((struct foo *)key)->one) : : l_yes);
>> +	}
>>   
>>   	return false;
>>   l_yes:
>> @@ -33,14 +48,25 @@ static __always_inline bool
>arch_static_branch(struct static_key *key, bool bran
>>   
>>   static __always_inline bool arch_static_branch_jump(struct
>static_key *key, bool branch)
>>   {
>> -	asm_volatile_goto("1:"
>> -		".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
>> -		"2:\n\t"
>> -		".pushsection __jump_table,  \"aw\" \n\t"
>> -		_ASM_ALIGN "\n\t"
>> -		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
>> -		".popsection \n\t"
>> -		: :  "i" (&((char *)key)[branch]) : : l_yes);
>> +	if (!branch) {
>> +		asm_volatile_goto("1:"
>> +				".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
>> +				"2:\n\t"
>> +				".pushsection __jump_table,  \"aw\" \n\t"
>> +				_ASM_ALIGN "\n\t"
>> +				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
>> +				".popsection \n\t"
>> +				: :  "i" (&((struct foo *)key)->zero) : : l_yes);
>> +	} else {
>> +		asm_volatile_goto("1:"
>> +				".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
>> +				"2:\n\t"
>> +				".pushsection __jump_table,  \"aw\" \n\t"
>> +				_ASM_ALIGN "\n\t"
>> +				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
>> +				".popsection \n\t"
>> +				: :  "i" (&((struct foo *)key)->one) : : l_yes);
>> +	}
>>   
>>   	return false;
>>   l_yes:

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Andy Lutomirski]

On Wed, Aug 12, 2015 at 11:17 AM, Boris Ostrovsky
<boris.ostrovsky@oracle.com> wrote:
> On 08/12/2015 01:46 PM, Peter Zijlstra wrote:
>>
>> On Wed, Aug 12, 2015 at 07:21:05PM +0200, Peter Zijlstra wrote:
>>>
>>> On Wed, Aug 12, 2015 at 09:27:38AM -0400, Boris Ostrovsky wrote:
>>>
>>>> Incidentally, 11276d53 ("locking/static_keys: Add a new static_key
>>>> interface") breaks old-ish compilers (gcc version 4.4.4 20100503 (Red
>>>> Hat
>>>> 4.4.4-2) (GCC)):
>>>>
>>>>
>>>>
>>>>    CC      arch/x86/kernel/nmi.o
>>>> In file included from
>>>> /home/build/linux-boris/include/linux/jump_label.h:109,
>>>>                   from
>>>> /home/build/linux-boris/arch/x86/include/asm/spinlock.h:5,
>>>>                   from
>>>> /home/build/linux-boris/include/linux/spinlock.h:88,
>>>>                   from /home/build/linux-boris/arch/x86/kernel/nmi.c:14:
>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h: In function
>>>> ‘nmi_handle’:
>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: warning:
>>>> asm
>>>> operand 0 probably doesn’t match constraints
>>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: error:
>>>> impossible constraint in ‘asm’
>>>> make[3]: *** [arch/x86/kernel/nmi.o] Error 1
>>>> make[2]: *** [arch/x86/kernel] Error 2
>>>> make[1]: *** [arch/x86] Error 2
>>>
>>> Ugh bugger.
>>>
>>> I bet its that: &((char *)key)[branch] business, an earlier variant
>>> thereof tripped up more recent GCCs too.
>>>
>>> So its an __always_inline function, and both argument are always compile
>>> time constants, @key is the address of an object in static storage (a
>>> global) and @branch is a simple 0/1 at the call site.
>>>
>>> Now we wish to compute (unsigned long)key + branch at compile/link time
>>> to feed to the assembler as an immediate, which should be possible,
>>> given its all 'constants'.
>>>
>>> It just appears GCC is having a hard time with this.
>>>
>>> Let me see if I have a sufficiently old GCC around to play with.
>>
>> Could you feed the below to your compiler? Its a bit cumbersome, but
>> its the next best I could come up with...
>
>
> No, it produces the same error. This is Fedora 13, btw, uses gcc 4.4.4.

Is the problem just that it's being misdetected as supporting asm
goto?  What does gcc -E say?

--Andy

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Boris Ostrovsky]

On 08/12/2015 01:46 PM, Peter Zijlstra wrote:
> On Wed, Aug 12, 2015 at 07:21:05PM +0200, Peter Zijlstra wrote:
>> On Wed, Aug 12, 2015 at 09:27:38AM -0400, Boris Ostrovsky wrote:
>>
>>> Incidentally, 11276d53 ("locking/static_keys: Add a new static_key
>>> interface") breaks old-ish compilers (gcc version 4.4.4 20100503 (Red Hat
>>> 4.4.4-2) (GCC)):
>>>
>>>
>>>
>>>    CC      arch/x86/kernel/nmi.o
>>> In file included from
>>> /home/build/linux-boris/include/linux/jump_label.h:109,
>>>                   from
>>> /home/build/linux-boris/arch/x86/include/asm/spinlock.h:5,
>>>                   from /home/build/linux-boris/include/linux/spinlock.h:88,
>>>                   from /home/build/linux-boris/arch/x86/kernel/nmi.c:14:
>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h: In function
>>> ‘nmi_handle’:
>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: warning: asm
>>> operand 0 probably doesn’t match constraints
>>> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: error:
>>> impossible constraint in ‘asm’
>>> make[3]: *** [arch/x86/kernel/nmi.o] Error 1
>>> make[2]: *** [arch/x86/kernel] Error 2
>>> make[1]: *** [arch/x86] Error 2
>> Ugh bugger.
>>
>> I bet its that: &((char *)key)[branch] business, an earlier variant
>> thereof tripped up more recent GCCs too.
>>
>> So its an __always_inline function, and both argument are always compile
>> time constants, @key is the address of an object in static storage (a
>> global) and @branch is a simple 0/1 at the call site.
>>
>> Now we wish to compute (unsigned long)key + branch at compile/link time
>> to feed to the assembler as an immediate, which should be possible,
>> given its all 'constants'.
>>
>> It just appears GCC is having a hard time with this.
>>
>> Let me see if I have a sufficiently old GCC around to play with.
> Could you feed the below to your compiler? Its a bit cumbersome, but
> its the next best I could come up with...

No, it produces the same error. This is Fedora 13, btw, uses gcc 4.4.4.

-boris


>
> ---
>   arch/x86/include/asm/jump_label.h | 56 ++++++++++++++++++++++++++++-----------
>   1 file changed, 41 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/include/asm/jump_label.h b/arch/x86/include/asm/jump_label.h
> index 28d7a857f9d1..76c769ae4200 100644
> --- a/arch/x86/include/asm/jump_label.h
> +++ b/arch/x86/include/asm/jump_label.h
> @@ -16,15 +16,30 @@
>   # define STATIC_KEY_INIT_NOP GENERIC_NOP5_ATOMIC
>   #endif
>   
> +struct foo {
> +	u8 zero;
> +	u8 one;
> +};
> +
>   static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
>   {
> -	asm_volatile_goto("1:"
> -		".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
> -		".pushsection __jump_table,  \"aw\" \n\t"
> -		_ASM_ALIGN "\n\t"
> -		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> -		".popsection \n\t"
> -		: :  "i" (&((char *)key)[branch]) : : l_yes);
> +	if (!branch) {
> +		asm_volatile_goto("1:"
> +				".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
> +				".pushsection __jump_table,  \"aw\" \n\t"
> +				_ASM_ALIGN "\n\t"
> +				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> +				".popsection \n\t"
> +				: :  "i" (&((struct foo *)key)->zero) : : l_yes);
> +	} else {
> +		asm_volatile_goto("1:"
> +				".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
> +				".pushsection __jump_table,  \"aw\" \n\t"
> +				_ASM_ALIGN "\n\t"
> +				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> +				".popsection \n\t"
> +				: :  "i" (&((struct foo *)key)->one) : : l_yes);
> +	}
>   
>   	return false;
>   l_yes:
> @@ -33,14 +48,25 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
>   
>   static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
>   {
> -	asm_volatile_goto("1:"
> -		".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
> -		"2:\n\t"
> -		".pushsection __jump_table,  \"aw\" \n\t"
> -		_ASM_ALIGN "\n\t"
> -		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> -		".popsection \n\t"
> -		: :  "i" (&((char *)key)[branch]) : : l_yes);
> +	if (!branch) {
> +		asm_volatile_goto("1:"
> +				".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
> +				"2:\n\t"
> +				".pushsection __jump_table,  \"aw\" \n\t"
> +				_ASM_ALIGN "\n\t"
> +				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> +				".popsection \n\t"
> +				: :  "i" (&((struct foo *)key)->zero) : : l_yes);
> +	} else {
> +		asm_volatile_goto("1:"
> +				".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
> +				"2:\n\t"
> +				".pushsection __jump_table,  \"aw\" \n\t"
> +				_ASM_ALIGN "\n\t"
> +				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> +				".popsection \n\t"
> +				: :  "i" (&((struct foo *)key)->one) : : l_yes);
> +	}
>   
>   	return false;
>   l_yes:

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Peter Zijlstra]

On Wed, Aug 12, 2015 at 07:21:05PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 12, 2015 at 09:27:38AM -0400, Boris Ostrovsky wrote:
> 
> > Incidentally, 11276d53 ("locking/static_keys: Add a new static_key
> > interface") breaks old-ish compilers (gcc version 4.4.4 20100503 (Red Hat
> > 4.4.4-2) (GCC)):
> > 
> > 
> > 
> >   CC      arch/x86/kernel/nmi.o
> > In file included from
> > /home/build/linux-boris/include/linux/jump_label.h:109,
> >                  from
> > /home/build/linux-boris/arch/x86/include/asm/spinlock.h:5,
> >                  from /home/build/linux-boris/include/linux/spinlock.h:88,
> >                  from /home/build/linux-boris/arch/x86/kernel/nmi.c:14:
> > /home/build/linux-boris/arch/x86/include/asm/jump_label.h: In function
> > ‘nmi_handle’:
> > /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: warning: asm
> > operand 0 probably doesn’t match constraints
> > /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: error:
> > impossible constraint in ‘asm’
> > make[3]: *** [arch/x86/kernel/nmi.o] Error 1
> > make[2]: *** [arch/x86/kernel] Error 2
> > make[1]: *** [arch/x86] Error 2
> 
> Ugh bugger.
> 
> I bet its that: &((char *)key)[branch] business, an earlier variant
> thereof tripped up more recent GCCs too.
> 
> So its an __always_inline function, and both argument are always compile
> time constants, @key is the address of an object in static storage (a
> global) and @branch is a simple 0/1 at the call site.
> 
> Now we wish to compute (unsigned long)key + branch at compile/link time
> to feed to the assembler as an immediate, which should be possible,
> given its all 'constants'.
> 
> It just appears GCC is having a hard time with this.
> 
> Let me see if I have a sufficiently old GCC around to play with.

Could you feed the below to your compiler? Its a bit cumbersome, but
its the next best I could come up with...

---
 arch/x86/include/asm/jump_label.h | 56 ++++++++++++++++++++++++++++-----------
 1 file changed, 41 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/jump_label.h b/arch/x86/include/asm/jump_label.h
index 28d7a857f9d1..76c769ae4200 100644
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -16,15 +16,30 @@
 # define STATIC_KEY_INIT_NOP GENERIC_NOP5_ATOMIC
 #endif
 
+struct foo {
+	u8 zero;
+	u8 one;
+};
+
 static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
 {
-	asm_volatile_goto("1:"
-		".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
-		".pushsection __jump_table,  \"aw\" \n\t"
-		_ASM_ALIGN "\n\t"
-		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
-		".popsection \n\t"
-		: :  "i" (&((char *)key)[branch]) : : l_yes);
+	if (!branch) {
+		asm_volatile_goto("1:"
+				".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
+				".pushsection __jump_table,  \"aw\" \n\t"
+				_ASM_ALIGN "\n\t"
+				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
+				".popsection \n\t"
+				: :  "i" (&((struct foo *)key)->zero) : : l_yes);
+	} else {
+		asm_volatile_goto("1:"
+				".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
+				".pushsection __jump_table,  \"aw\" \n\t"
+				_ASM_ALIGN "\n\t"
+				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
+				".popsection \n\t"
+				: :  "i" (&((struct foo *)key)->one) : : l_yes);
+	}
 
 	return false;
 l_yes:
@@ -33,14 +48,25 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
 
 static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
 {
-	asm_volatile_goto("1:"
-		".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
-		"2:\n\t"
-		".pushsection __jump_table,  \"aw\" \n\t"
-		_ASM_ALIGN "\n\t"
-		_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
-		".popsection \n\t"
-		: :  "i" (&((char *)key)[branch]) : : l_yes);
+	if (!branch) {
+		asm_volatile_goto("1:"
+				".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
+				"2:\n\t"
+				".pushsection __jump_table,  \"aw\" \n\t"
+				_ASM_ALIGN "\n\t"
+				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
+				".popsection \n\t"
+				: :  "i" (&((struct foo *)key)->zero) : : l_yes);
+	} else {
+		asm_volatile_goto("1:"
+				".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
+				"2:\n\t"
+				".pushsection __jump_table,  \"aw\" \n\t"
+				_ASM_ALIGN "\n\t"
+				_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
+				".popsection \n\t"
+				: :  "i" (&((struct foo *)key)->one) : : l_yes);
+	}
 
 	return false;
 l_yes:

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Peter Zijlstra]

On Wed, Aug 12, 2015 at 07:21:05PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 12, 2015 at 09:27:38AM -0400, Boris Ostrovsky wrote:
> 
> > Incidentally, 11276d53 ("locking/static_keys: Add a new static_key
> > interface") breaks old-ish compilers (gcc version 4.4.4 20100503 (Red Hat
> > 4.4.4-2) (GCC)):
> > 
> > 
> > 
> >   CC      arch/x86/kernel/nmi.o
> > In file included from
> > /home/build/linux-boris/include/linux/jump_label.h:109,
> >                  from
> > /home/build/linux-boris/arch/x86/include/asm/spinlock.h:5,
> >                  from /home/build/linux-boris/include/linux/spinlock.h:88,
> >                  from /home/build/linux-boris/arch/x86/kernel/nmi.c:14:
> > /home/build/linux-boris/arch/x86/include/asm/jump_label.h: In function
> > ‘nmi_handle’:
> > /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: warning: asm
> > operand 0 probably doesn’t match constraints
> > /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: error:
> > impossible constraint in ‘asm’
> > make[3]: *** [arch/x86/kernel/nmi.o] Error 1
> > make[2]: *** [arch/x86/kernel] Error 2
> > make[1]: *** [arch/x86] Error 2
> 
> Ugh bugger.
> 
> I bet its that: &((char *)key)[branch] business, an earlier variant
> thereof tripped up more recent GCCs too.
> 
> So its an __always_inline function, and both argument are always compile
> time constants, @key is the address of an object in static storage (a
> global) and @branch is a simple 0/1 at the call site.
> 
> Now we wish to compute (unsigned long)key + branch at compile/link time
> to feed to the assembler as an immediate, which should be possible,
> given its all 'constants'.
> 
> It just appears GCC is having a hard time with this.
> 
> Let me see if I have a sufficiently old GCC around to play with.

So both my 4.4 compilers:

gcc-4.4 (Ubuntu/Linaro 4.4.7-8ubuntu1) 4.4.7
gcc-4.4 (Debian 4.4.7-2) 4.4.7

Do not have CC_HAVE_ASM_GOTO at all, and my gcc-4.6 (my next oldest
compiler) doesn't have trouble building this.

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Peter Zijlstra]

On Wed, Aug 12, 2015 at 09:27:38AM -0400, Boris Ostrovsky wrote:

> Incidentally, 11276d53 ("locking/static_keys: Add a new static_key
> interface") breaks old-ish compilers (gcc version 4.4.4 20100503 (Red Hat
> 4.4.4-2) (GCC)):
> 
> 
> 
>   CC      arch/x86/kernel/nmi.o
> In file included from
> /home/build/linux-boris/include/linux/jump_label.h:109,
>                  from
> /home/build/linux-boris/arch/x86/include/asm/spinlock.h:5,
>                  from /home/build/linux-boris/include/linux/spinlock.h:88,
>                  from /home/build/linux-boris/arch/x86/kernel/nmi.c:14:
> /home/build/linux-boris/arch/x86/include/asm/jump_label.h: In function
> ‘nmi_handle’:
> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: warning: asm
> operand 0 probably doesn’t match constraints
> /home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: error:
> impossible constraint in ‘asm’
> make[3]: *** [arch/x86/kernel/nmi.o] Error 1
> make[2]: *** [arch/x86/kernel] Error 2
> make[1]: *** [arch/x86] Error 2

Ugh bugger.

I bet its that: &((char *)key)[branch] business, an earlier variant
thereof tripped up more recent GCCs too.

So its an __always_inline function, and both argument are always compile
time constants, @key is the address of an object in static storage (a
global) and @branch is a simple 0/1 at the call site.

Now we wish to compute (unsigned long)key + branch at compile/link time
to feed to the assembler as an immediate, which should be possible,
given its all 'constants'.

It just appears GCC is having a hard time with this.

Let me see if I have a sufficiently old GCC around to play with.

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Boris Ostrovsky]

On 08/12/2015 01:09 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
>
>    arch/x86/xen/enlighten.c
>
> between commit:
>
>    9261e050b686 ("x86/asm/tsc, x86/paravirt: Remove read_tsc() and read_tscp() paravirt hooks")
>
> from the tip tree and commit:
>
>    cd6f350a5460 ("xen/PMU: Initialization code for Xen PMU")
>
> from the xen-tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks, this looks good.

Incidentally, 11276d53 ("locking/static_keys: Add a new static_key 
interface") breaks old-ish compilers (gcc version 4.4.4 20100503 (Red 
Hat 4.4.4-2) (GCC)):



   CC      arch/x86/kernel/nmi.o
In file included from 
/home/build/linux-boris/include/linux/jump_label.h:109,
                  from 
/home/build/linux-boris/arch/x86/include/asm/spinlock.h:5,
                  from /home/build/linux-boris/include/linux/spinlock.h:88,
                  from /home/build/linux-boris/arch/x86/kernel/nmi.c:14:
/home/build/linux-boris/arch/x86/include/asm/jump_label.h: In function 
‘nmi_handle’:
/home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: warning: 
asm operand 0 probably doesn’t match constraints
/home/build/linux-boris/arch/x86/include/asm/jump_label.h:21: error: 
impossible constraint in ‘asm’
make[3]: *** [arch/x86/kernel/nmi.o] Error 1
make[2]: *** [arch/x86/kernel] Error 2
make[1]: *** [arch/x86] Error 2


-boris

>
> -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc 
> arch/x86/xen/enlighten.c index d9cfa452da9d,a1c2e46206a9..000000000000 
> --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@@ 
> -1215,8 -1179,11 +1219,8 @@@ static const struct pv_cpu_ops xen_cpu_ 
> .read_msr = xen_read_msr_safe, .write_msr = xen_write_msr_safe, - 
> .read_pmc = native_read_pmc, - .read_tsc = native_read_tsc, + 
> .read_pmc = xen_read_pmc, - .read_tscp = native_read_tscp, - .iret = 
> xen_iret, #ifdef CONFIG_X86_64 .usergs_sysret32 = xen_sysret32,

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/enlighten.c

between commit:

  9261e050b686 ("x86/asm/tsc, x86/paravirt: Remove read_tsc() and read_tscp() paravirt hooks")

from the tip tree and commit:

  cd6f350a5460 ("xen/PMU: Initialization code for Xen PMU")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/xen/enlighten.c
index d9cfa452da9d,a1c2e46206a9..000000000000
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@@ -1215,8 -1179,11 +1219,8 @@@ static const struct pv_cpu_ops xen_cpu_
  	.read_msr = xen_read_msr_safe,
  	.write_msr = xen_write_msr_safe,
  
- 	.read_pmc = native_read_pmc,
 -	.read_tsc = native_read_tsc,
+ 	.read_pmc = xen_read_pmc,
  
 -	.read_tscp = native_read_tscp,
 -
  	.iret = xen_iret,
  #ifdef CONFIG_X86_64
  	.usergs_sysret32 = xen_sysret32,

linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in
drivers/xen/events/events_base.c between commit 02893afdd310 ("xen: Get
rid of the last irq_desc abuse") from the tip tree and commit
8fb980538510 ("xen: add support for MSI message groups") from the xen-tip
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/xen/events/events_base.c
index c3458f58de90,793053065629..000000000000
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@@ -767,7 -788,16 +776,12 @@@ int xen_destroy_irq(int irq
  
  	mutex_lock(&irq_mapping_update_lock);
  
- 	if (xen_initial_domain()) {
 -	desc = irq_to_desc(irq);
 -	if (!desc)
 -		goto out;
 -
+ 	/*
+ 	 * If trying to remove a vector in a MSI group different
+ 	 * than the first one skip the PIRQ unmap unless this vector
+ 	 * is the first one in the group.
+ 	 */
+ 	if (xen_initial_domain() && !(info->u.pirq.flags & PIRQ_MSI_GROUP)) {
  		unmap_irq.pirq = info->u.pirq.pirq;
  		unmap_irq.domid = info->u.pirq.domid;
  		rc = HYPERVISOR_physdev_op(PHYSDEVOP_unmap_pirq, &unmap_irq);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]