Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

[Steven Haigh]

On 2018-05-22 20:52, Steven Haigh wrote:

On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:

>>> On 18.05.18 at 19:53,  wrote:
> Alternative workaround for this would be more frequent point releases by
> default (maybe with ability to delay it very few commits are queued).
> For example every 3 months. It wouldn't solve all the cases, but I think
> will make it easier most of the time.

Is every 3 months so much better than every 4 months? Granted we
basically never manage to make it exactly 4 months, but on the average
I think we're not too far off.


I think the big thing is reducing the delta between the staging branch 
and the
release. I can only assume that would reduce the number of issues that 
occur
with patching vs release tarballs - hopefully making the security teams 
job a

little easier.

That being said, if an approach of releasing a new build when we come 
across
broken patch sets for XSAs (like the current 4.9.1 vs XSAs, and prior 
4.10.0

vs XSAs), then I think this part becomes irrelevant.


As another example for this, the patches for XSA263 do not apply to 
*any* released tarball version of Xen.


So far, the patches included with the announcement fail on 4.6, 4.7, 4.9 
and 4.10.


I can only assume that this means all the XSA patches require commits 
that are currently in various staging git trees that have not been 
released in any formal manner via a point release.


--
Steven Haigh

? net...@crc.id.au ? https://www.crc.id.au
? +61 (3) 9001 6090? 0412 935 897

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

[Matthew Wilcox]

On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote:
> So why is this any better than the current code. Sure I am not a great
> fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
> doesn't look too much better, yet we are losing a check for incompatible
> gfp flags. The diffstat looks really sound but then you just look and
> see that the large part is the comment that at least explained the gfp
> zone modifiers somehow and the debugging code. So what is the selling
> point?

I have a plan, but it's not exactly fully-formed yet.

One of the big problems we have today is that we have a lot of users
who have constraints on the physical memory they want to allocate,
but we have very limited abilities to provide them with what they're
asking for.  The various different ZONEs have different meanings on
different architectures and are generally a mess.

If we had eight ZONEs, we could offer:

ZONE_16M// 24 bit
ZONE_256M   // 28 bit
ZONE_LOWMEM // CONFIG_32BIT only
ZONE_4G // 32 bit
ZONE_64G// 36 bit
ZONE_1T // 40 bit
ZONE_ALL// everything larger
ZONE_MOVABLE// movable allocations; no physical address guarantees

#ifdef CONFIG_64BIT
#define ZONE_NORMAL ZONE_ALL
#else
#define ZONE_NORMAL ZONE_LOWMEM
#endif

This would cover most driver DMA mask allocations; we could tweak the
offered zones based on analysis of what people need.

#define GFP_HIGHUSER(GFP_USER | ZONE_ALL)
#define GFP_HIGHUSER_MOVABLE(GFP_USER | ZONE_MOVABLE)

One other thing I want to see is that fallback from zones happens from
highest to lowest normally (ie if you fail to allocate in 1T, then you
try to allocate from 64G), but movable allocations hapen from lowest
to highest.  So ZONE_16M ends up full of page cache pages which are
readily evictable for the rare occasions when we need to allocate memory
below 16MB.

I'm sure there are lots of good reasons why this won't work, which is
why I've been hesitant to propose it before now.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

Hi Sameer,

General Comment, please use appropriate variable names for XXX_domain 
structures in code which is xen specific.



On 05/24/2018 06:16 AM, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- xen/linux_compat: Add a Linux compat header
   For porting files directly from Linux it is useful to have a function mapping
   definitions from Linux to Xen. This file adds common API functions and
   other defines that are needed for porting arm SMMU drivers.

Signed-off-by: Sameer Goel 
---
  xen/arch/arm/p2m.c|   1 +
  xen/drivers/Kconfig   |   2 +
  xen/drivers/passthrough/arm/Kconfig   |   8 +
  xen/drivers/passthrough/arm/Makefile  |   1 +
  xen/drivers/passthrough/arm/smmu-v3.c | 934 +-
  xen/include/xen/linux_compat.h|  84 +++
  6 files changed, 1001 insertions(+), 29 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/Kconfig
  create mode 100644 xen/include/xen/linux_compat.h

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..38aa9f00c1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1454,6 +1454,7 @@ err:
  static void __init setup_virt_paging_one(void *data)
  {
  unsigned long val = (unsigned long)data;
+/* SMMUv3 S2 cfg vtcr reuses the following value */
  WRITE_SYSREG32(val, VTCR_EL2);
  isb();
  }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index db94393f47..59ca00f850 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -15,4 +15,6 @@ source "drivers/video/Kconfig"
  config HAS_VPCI
bool
  
+source "drivers/passthrough/arm/Kconfig"

+
  endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
  obj-y += iommu.o
  obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..df81626785 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,414 @@
   * Author: Will Deacon 
   *
   * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
   */
  
-#include 

-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "io-pgtable.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if 

[Xen-devel] [linux-next test] 123049: regressions - FAIL

[osstest service owner]

flight 123049 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123049/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  6 xen-install  fail REGR. vs. 122855
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 122855
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 122855
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 122855
 test-armhf-armhf-libvirt  7 xen-boot fail REGR. vs. 122855
 test-armhf-armhf-xl-credit2   7 xen-boot fail REGR. vs. 122855
 test-armhf-armhf-libvirt-raw  7 xen-boot fail REGR. vs. 122855
 test-armhf-armhf-xl-cubietruck  7 xen-boot   fail REGR. vs. 122855

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm 5 host-ping-check-native fail in 122966 pass in 
123049
 test-armhf-armhf-xl   7 xen-boot   fail pass in 122966

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  7 xen-boot fail REGR. vs. 122855

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl 13 migrate-support-check fail in 122966 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 122966 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122855
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122855
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122855
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122855
 test-armhf-armhf-xl-arndale  10 debian-install   fail  like 122855
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122855
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122855
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122855
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxfbbe3b8c2c9c5f84caf668703c26154cb4fbb9d1
baseline version:
 linux21b9f1c7e319f654de3b2574fe8d4e4114c9143f

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   122966  2018-05-19 07:17:41 Z4 days2 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt   

Re: [Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation

[Stefano Stabellini]

On Wed, 23 May 2018, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
> > On a system where the firmware implements ARCH_WORKAROUND_2, it may be
> > useful to either permanently enable or disable the workaround for cases
> > where the user decides that they'd rather not get a trap overhead, and
> > keep the mitigation permanently on or off instead of switching it on
> > exception entry/exit.
> > 
> > In any case, default to mitigation being enabled.
> > 
> > At the same time provide a accessor to know the state of the mitigation.
> > 
> > SIgned-off-by: Julien Grall 
> > ---
> >  docs/misc/xen-command-line.markdown |  18 ++
> >  xen/arch/arm/cpuerrata.c| 115 
> > 
> >  xen/include/asm-arm/cpuerrata.h |  21 +++
> >  xen/include/asm-arm/smccc.h |   1 +
> >  4 files changed, 144 insertions(+), 11 deletions(-)
> > 
> > diff --git a/docs/misc/xen-command-line.markdown 
> > b/docs/misc/xen-command-line.markdown
> > index 8712a833a2..962028b6ed 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout 
> > of 670ms. Any number
> >  is being interpreted as a custom timeout in milliseconds. Zero or boolean
> >  false disable the quirk workaround, which is also the default.
> >  
> > +### spec-ctrl (Arm)
> > +> `= List of [ ssbd=force-disable|runtime|force-enable ]`
> 
> Why a list? Shouldn't it be one or the other?
> 
> > +Controls for speculative execution sidechannel mitigations.
> > +
> > +The option `ssbd=` is used to control the state of Speculative Store
> > +Bypass Disable (SSBD) mitigation.
> > +
> > +* `ssbd=force-disable` will keep the mitigation permanently off. The guest
> > +will not be able to control the state of the mitigation.
> > +* `ssbd=runtime` will always turn on the mitigation when running in the
> > +hypervisor context. The guest will be to turn on/off the mitigation for
> > +itself by using the firmware interface ARCH\_WORKAROUND\_2.
> > +* `ssbd=force-enable` will keep the mitigation permanently on. The guest 
> > will
> > +not be able to control the state of the mitigation.
> > +
> > +By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
> > +
> >  ### spec-ctrl (x86)
> >  > `= List of [ , xen=, {pv,hvm,msr-sc,rsb}=,
> >  >  bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}= ]`
> > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> > index bcea2eb6e5..f921721a66 100644
> > --- a/xen/arch/arm/cpuerrata.c
> > +++ b/xen/arch/arm/cpuerrata.c
> > @@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
> >  
> >  #ifdef CONFIG_ARM_SSBD
> >  
> > +enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
> > +
> > +static int __init parse_spec_ctrl(const char *s)
> > +{
> > +const char *ss;
> > +int rc = 0;
> > +
> > +do {
> > +ss = strchr(s, ',');
> > +if ( !ss )
> > +ss = strchr(s, '\0');
> 
> It doesn't look like it is necessary to parse ',' at all. I would remove
> the while loop too.
> 
> 
> > +if ( !strncmp(s, "ssbd=", 5) )
> > +{
> > +s += 5;
> > +
> > +if ( !strncmp(s, "force-disable", ss - s) )
> > +ssbd_state = ARM_SSBD_FORCE_DISABLE;
> > +else if ( !strncmp(s, "runtime", ss - s) )
> > +ssbd_state = ARM_SSBD_RUNTIME;
> > +else if ( !strncmp(s, "force-enable", ss - s) )
> > +ssbd_state = ARM_SSBD_FORCE_ENABLE;
> > +else
> > +rc = -EINVAL;
> > +}
> > +else
> > +rc = -EINVAL;
> > +
> > +s = ss + 1;
> > +} while ( *ss );
> > +
> > +return rc;
> > +}
> > +custom_param("spec-ctrl", parse_spec_ctrl);
> > +
> >  /*
> >   * Assembly code may use the variable directly, so we need to make sure
> >   * it fits in a register.
> > @@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t, 
> > ssbd_callback_required);
> >  static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
> >  {
> >  struct arm_smccc_res res;
> > -bool supported = true;
> > +bool required = true;
> 
> Please avoid this renaming. Choose one name or the other from the start.
> 
> 
> >  if ( smccc_ver < SMCCC_VERSION(1, 1) )
> >  return false;
> >  
> > -/*
> > - * The probe function return value is either negative (unsupported
> > - * or mitigated), positive (unaffected), or zero (requires
> > - * mitigation). We only need to do anything in the last case.
> > - */
> 
> I would keep the comment
> 
> 
> >  arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> >ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
> > -if ( (int)res.a0 != 0 )
> > -supported = false;
> >  
> > -if ( supported )
> > -this_cpu(ssbd_callback_required) = 1;
> > +switch ( 

[Xen-devel] [v2 2/6] passthrough/arm: Modify SMMU driver to use generic device definition

[Sameer Goel]

Modify the SMMU code to use generic device instead of dt_device_node for
functions that can be used for ACPI based systems too.

Signed-off-by: Sameer Goel 
Acked-by: Julien Grall 
---
 xen/drivers/passthrough/arm/smmu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 45acb89380..ad956d5b8d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -76,7 +76,7 @@ struct resource
 
 #define resource_size(res) (res)->size;
 
-#define platform_device dt_device_node
+#define platform_device device
 
 #define IORESOURCE_MEM 0
 #define IORESOURCE_IRQ 1
@@ -97,12 +97,12 @@ static struct resource *platform_get_resource(struct 
platform_device *pdev,
 
switch (type) {
case IORESOURCE_MEM:
-   ret = dt_device_get_address(pdev, num, , );
+   ret = dt_device_get_address(dev_to_dt(pdev), num, , 
);
 
return ((ret) ? NULL : );
 
case IORESOURCE_IRQ:
-   ret = platform_get_irq(pdev, num);
+   ret = platform_get_irq(dev_to_dt(pdev), num);
if (ret < 0)
return NULL;
 
@@ -2286,7 +2286,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
const struct of_device_id *of_id;
struct resource *res;
struct arm_smmu_device *smmu;
-   struct device *dev = >dev;
+   struct device *dev = pdev;
struct rb_node *node;
struct of_phandle_args masterspec;
int num_irqs, i, err;
@@ -2339,7 +2339,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
}
 
for (i = 0; i < num_irqs; ++i) {
-   int irq = platform_get_irq(pdev, i);
+   int irq = platform_get_irq(dev_to_dt(pdev), i);
 
if (irq < 0) {
dev_err(dev, "failed to get irq index %d\n", i);
@@ -2820,7 +2820,7 @@ static __init int arm_smmu_dt_init(struct dt_device_node 
*dev,
 */
dt_device_set_used_by(dev, DOMID_XEN);
 
-   rc = arm_smmu_device_dt_probe(dev);
+   rc = arm_smmu_device_dt_probe(dt_to_dev(dev));
if (rc)
return rc;
 
-- 
2.17.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [v2 6/6] xen/smmu: Add a new config define for legacy SMMU

[Sameer Goel]

Add a new config item to control compilation for legacy arm SMMU.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/Kconfig  | 6 ++
 xen/drivers/passthrough/arm/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
index cda899f608..e888a78312 100644
--- a/xen/drivers/passthrough/arm/Kconfig
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -6,3 +6,9 @@ config ARM_SMMU_v3
 Support for implementations of the ARM System MMU architecture
 version 3.
 
+config ARM_SMMU
+   bool "ARM Legacy SMMU Support"
+   depends on ARM
+   help
+Support for implementations of the ARM System MMU architecture
+version 1 and 2.
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index e14732b55c..5b3eb1545e 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,3 +1,3 @@
 obj-y += iommu.o
-obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU) += smmu.o
 obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
-- 
2.17.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [v2 3/6] Add verbatim copy of arm-smmu-v3.c from Linux

[Sameer Goel]

Based on commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
This is a verbatim snapshot of arm-smmu-v3.c from Linux kernel source
code.
No Xen code has been added and the file is not built.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/smmu-v3.c | 2885 +
 1 file changed, 2885 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/smmu-v3.c

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
new file mode 100644
index 00..e67ba6c40f
--- /dev/null
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -0,0 +1,2885 @@
+/*
+ * IOMMU API for ARM architected SMMUv3 implementations.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Will Deacon 
+ *
+ * This driver is powered by bad coffee and bombay mix.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "io-pgtable.h"
+
+/* MMIO registers */
+#define ARM_SMMU_IDR0  0x0
+#define IDR0_ST_LVL_SHIFT  27
+#define IDR0_ST_LVL_MASK   0x3
+#define IDR0_ST_LVL_2LVL   (1 << IDR0_ST_LVL_SHIFT)
+#define IDR0_STALL_MODEL_SHIFT 24
+#define IDR0_STALL_MODEL_MASK  0x3
+#define IDR0_STALL_MODEL_STALL (0 << IDR0_STALL_MODEL_SHIFT)
+#define IDR0_STALL_MODEL_FORCE (2 << IDR0_STALL_MODEL_SHIFT)
+#define IDR0_TTENDIAN_SHIFT21
+#define IDR0_TTENDIAN_MASK 0x3
+#define IDR0_TTENDIAN_LE   (2 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_TTENDIAN_BE   (3 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_TTENDIAN_MIXED(0 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_CD2L  (1 << 19)
+#define IDR0_VMID16(1 << 18)
+#define IDR0_PRI   (1 << 16)
+#define IDR0_SEV   (1 << 14)
+#define IDR0_MSI   (1 << 13)
+#define IDR0_ASID16(1 << 12)
+#define IDR0_ATS   (1 << 10)
+#define IDR0_HYP   (1 << 9)
+#define IDR0_COHACC(1 << 4)
+#define IDR0_TTF_SHIFT 2
+#define IDR0_TTF_MASK  0x3
+#define IDR0_TTF_AARCH64   (2 << IDR0_TTF_SHIFT)
+#define IDR0_TTF_AARCH32_64(3 << IDR0_TTF_SHIFT)
+#define IDR0_S1P   (1 << 1)
+#define IDR0_S2P   (1 << 0)
+
+#define ARM_SMMU_IDR1  0x4
+#define IDR1_TABLES_PRESET (1 << 30)
+#define IDR1_QUEUES_PRESET (1 << 29)
+#define IDR1_REL   (1 << 28)
+#define IDR1_CMDQ_SHIFT21
+#define IDR1_CMDQ_MASK 0x1f
+#define IDR1_EVTQ_SHIFT16
+#define IDR1_EVTQ_MASK 0x1f
+#define IDR1_PRIQ_SHIFT11
+#define IDR1_PRIQ_MASK 0x1f
+#define IDR1_SSID_SHIFT6
+#define IDR1_SSID_MASK 0x1f
+#define IDR1_SID_SHIFT 0
+#define IDR1_SID_MASK  0x3f
+
+#define ARM_SMMU_IDR5  0x14
+#define IDR5_STALL_MAX_SHIFT   16
+#define IDR5_STALL_MAX_MASK0x
+#define IDR5_GRAN64K   (1 << 6)
+#define IDR5_GRAN16K   (1 << 5)
+#define IDR5_GRAN4K(1 << 4)
+#define IDR5_OAS_SHIFT 0
+#define IDR5_OAS_MASK  0x7
+#define IDR5_OAS_32_BIT(0 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_36_BIT(1 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_40_BIT(2 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_42_BIT(3 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_44_BIT(4 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_48_BIT(5 << IDR5_OAS_SHIFT)
+
+#define ARM_SMMU_CR0   0x20
+#define CR0_CMDQEN (1 << 3)
+#define CR0_EVTQEN (1 << 2)
+#define CR0_PRIQEN (1 << 1)
+#define CR0_SMMUEN (1 << 0)
+
+#define ARM_SMMU_CR0ACK0x24
+
+#define ARM_SMMU_CR1   0x28
+#define CR1_SH_NSH 0

[Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Sameer Goel]

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- xen/linux_compat: Add a Linux compat header
  For porting files directly from Linux it is useful to have a function mapping
  definitions from Linux to Xen. This file adds common API functions and
  other defines that are needed for porting arm SMMU drivers.

Signed-off-by: Sameer Goel 
---
 xen/arch/arm/p2m.c|   1 +
 xen/drivers/Kconfig   |   2 +
 xen/drivers/passthrough/arm/Kconfig   |   8 +
 xen/drivers/passthrough/arm/Makefile  |   1 +
 xen/drivers/passthrough/arm/smmu-v3.c | 934 +-
 xen/include/xen/linux_compat.h|  84 +++
 6 files changed, 1001 insertions(+), 29 deletions(-)
 create mode 100644 xen/drivers/passthrough/arm/Kconfig
 create mode 100644 xen/include/xen/linux_compat.h

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..38aa9f00c1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1454,6 +1454,7 @@ err:
 static void __init setup_virt_paging_one(void *data)
 {
 unsigned long val = (unsigned long)data;
+/* SMMUv3 S2 cfg vtcr reuses the following value */
 WRITE_SYSREG32(val, VTCR_EL2);
 isb();
 }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index db94393f47..59ca00f850 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -15,4 +15,6 @@ source "drivers/video/Kconfig"
 config HAS_VPCI
bool
 
+source "drivers/passthrough/arm/Kconfig"
+
 endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
 obj-y += iommu.o
 obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..df81626785 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,414 @@
  * Author: Will Deacon 
  *
  * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "io-pgtable.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if (pdev->type == DEV_ACPI) {
+   ret = 1;
+   iort_node = pdev->acpi_node;
+   node_smmu_data =
+   (struct 

[Xen-devel] [v2 5/6] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Sameer Goel]

Pull common defines for SMMU drives in a local header.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/arm_smmu.h | 125 +
 xen/drivers/passthrough/arm/smmu-v3.c  |  96 +--
 xen/drivers/passthrough/arm/smmu.c | 104 +---
 3 files changed, 128 insertions(+), 197 deletions(-)
 create mode 100644 xen/drivers/passthrough/arm/arm_smmu.h

diff --git a/xen/drivers/passthrough/arm/arm_smmu.h 
b/xen/drivers/passthrough/arm/arm_smmu.h
new file mode 100644
index 00..f49dceb5b4
--- /dev/null
+++ b/xen/drivers/passthrough/arm/arm_smmu.h
@@ -0,0 +1,125 @@
+/**
+ * ./arm_smmu.h
+ *
+ * Common compatibility defines and data_structures for porting arm smmu
+ * drivers from Linux.
+ *
+ * Copyright (c) 2017 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#ifndef __ARM_SMMU_H__
+#define __ARM_SMMU_H__
+
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Helpers to get device MMIO and IRQs */
+struct resource {
+u64 addr;
+u64 size;
+unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+/* Stub out DMA domain related functions */
+#define iommu_get_dma_cookie(dom) 0
+#define iommu_put_dma_cookie(dom)
+
+#define VA_BITS0 /* Only used for configuring stage-1 input 
size */
+
+#define MODULE_DEVICE_TABLE(type, name)
+#define module_param_named(name, value, type, perm)
+#define MODULE_PARM_DESC(_parm, desc)
+
+#define dma_set_mask_and_coherent(d, b)0
+#define of_dma_is_coherent(n)  0
+
+static void __iomem *devm_ioremap_resource(struct device *dev,
+  struct resource *res)
+{
+void __iomem *ptr;
+
+if ( !res || res->type != IORESOURCE_MEM )
+{
+dev_err(dev, "Invalid resource\n");
+return ERR_PTR(-EINVAL);
+}
+
+ptr = ioremap_nocache(res->addr, res->size);
+if ( !ptr )
+{
+dev_err(dev, "ioremap failed (addr 0x%"PRIx64" size 0x%"PRIx64")\n",
+res->addr, res->size);
+return ERR_PTR(-ENOMEM);
+}
+
+return ptr;
+}
+
+/*
+ * Domain type definitions. Not really needed for Xen, defining to port
+ * Linux code as-is
+ */
+#define IOMMU_DOMAIN_UNMANAGED 0
+#define IOMMU_DOMAIN_DMA 1
+#define IOMMU_DOMAIN_IDENTITY 2
+
+/* Xen: Compatibility define for iommu_domain_geometry.*/
+struct iommu_domain_geometry {
+dma_addr_t aperture_start; /* First address that can be mapped*/
+dma_addr_t aperture_end;   /* Last address that can be mapped */
+bool force_aperture;   /* DMA only allowed in mappable range? */
+};
+
+/* Xen: Dummy iommu_domain */
+struct iommu_domain {
+/* Runtime SMMU configuration for this iommu_domain */
+struct arm_smmu_domain *priv;
+unsigned int   type;
+
+/* Dummy compatibility defines */
+unsigned long pgsize_bitmap;
+struct iommu_domain_geometry geometry;
+
+atomic_t ref;
+/* Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+struct list_head   list;
+};
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+spinlock_t lock;
+/* List of iommu domains associated to this domain */
+struct list_head   contexts;
+};
+
+#endif /* __ARM_SMMU_H__ */
+
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index df81626785..b43f0a892e 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -49,28 +49,7 @@
 #include 
 #include 
 
-/* Alias to Xen device tree helpers */
-#define device_node dt_device_node
-#define of_phandle_args dt_phandle_args
-#define of_device_id dt_device_match
-#define of_match_node 

[Xen-devel] [v2 1/6] Port WARN_ON_ONCE() from Linux

[Sameer Goel]

Port WARN_ON_ONCE macro from Linux.

Signed-off-by: Sameer Goel 
Acked-by: Julien Grall 
---
 xen/arch/arm/xen.lds.S |  1 +
 xen/arch/x86/xen.lds.S |  1 +
 xen/include/xen/lib.h  | 13 +
 3 files changed, 15 insertions(+)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 245a0e0e85..2f211be22f 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -94,6 +94,7 @@ SECTIONS
__end_schedulers_array = .;
*(.data.rel)
*(.data.rel.*)
+   *(.data.unlikely)
CONSTRUCTORS
   } :text
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 70afedd31d..11b2a93eb1 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,6 +270,7 @@ SECTIONS
*(.data)
*(.data.rel)
*(.data.rel.*)
+   *(.data.unlikely)
CONSTRUCTORS
   } :text
 
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 1d9771340c..b8442a292e 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -11,6 +11,19 @@
 #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
 #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
 
+#define WARN_ON_ONCE(p)   \
+({\
+static bool __section(".data.unlikely") warned;   \
+bool ret_warn_once = !!(p);   \
+  \
+if ( unlikely(ret_warn_once && !warned) ) \
+{ \
+warned = true;\
+WARN();   \
+} \
+unlikely(ret_warn_once);  \
+})
+
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
 /* Force a compilation error if condition is true */
 #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
-- 
2.17.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests

[Stefano Stabellini]

On Wed, 23 May 2018, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
> > In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
> > state of the workaround per-vCPU. The field 'pad' in cpu_info is now
> > repurposed to store flags easily accessible in assembly.
> > 
> > As the hypervisor will always run with the workaround enabled, we may
> > need to enable (on guest exit) or disable (on guest entry) the
> > workaround.
> > 
> > A follow-up patch will add fastpath for the workaround for arm64 guests.
> > 
> > This is part of XSA-263.
> > 
> > Signed-off-by: Julien Grall 
> > ---
> >  xen/arch/arm/domain.c |  8 
> >  xen/arch/arm/traps.c  | 20 
> >  xen/arch/arm/vsmc.c   | 37 +
> >  xen/include/asm-arm/current.h |  6 +-
> >  4 files changed, 70 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index e7b33e92fb..9168195a9c 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -575,6 +576,13 @@ int vcpu_initialise(struct vcpu *v)
> >  if ( (rc = vcpu_vtimer_init(v)) != 0 )
> >  goto fail;
> >  
> > +/*
> > + * The workaround 2 (i.e SSBD mitigation) is enabled by default if
> > + * supported.
> > + */
> > +if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
> > +v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
> > +
> >  return rc;
> >  
> >  fail:
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index 5c18e918b0..020b0b8eef 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -2011,10 +2011,23 @@ inject_abt:
> >  inject_iabt_exception(regs, gva, hsr.len);
> >  }
> >  
> > +static inline bool needs_ssbd_flip(struct vcpu *v)
> > +{
> > +if ( !check_workaround_ssbd() )
> > +return false;
> 
> Why not check on get_ssbd_state() == ARM_SSBD_RUNTIME?  I am confused on
> when is the right time to use the cpu capability check
> (check_workaround_ssbd), when is the right time to call get_ssbd_state()
> and when is the right time to call cpu_require_ssbd_mitigation().
> 
> 
> > +return !((v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
> > + cpu_require_ssbd_mitigation());
> 
> It looks like this won't do as intended when v->arch.cpu_info->flags = 0
> and cpu_require_ssbd_mitigation() returns false, am I right?
> 
> Maybe needs_ssbd_flip() should be implemented as follows:
> 
>   return get_ssbd_state() == ARM_SSBD_RUNTIME &&
> !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)

With the intention of supporting systems where not all CPUs need/have
the workaround, then it should be:

   return cpu_require_ssbd_mitigation() &&
 !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)
 

> > +}
> > +
> >  static void enter_hypervisor_head(struct cpu_user_regs *regs)
> >  {
> >  if ( guest_mode(regs) )
> >  {
> > +/* If the guest has disabled the workaround, bring it back on. */
> > +if ( needs_ssbd_flip(current) )
> > +arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > +
> >  /*
> >   * If we pended a virtual abort, preserve it until it gets cleared.
> >   * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for 
> > details,
> > @@ -2260,6 +2273,13 @@ void leave_hypervisor_tail(void)
> >   */
> >  SYNCHRONIZE_SERROR(SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT);
> >  
> > +/*
> > + * The hypervisor runs with the workaround always present.
> > + * If the guest wants it disabled, so be it...
> > + */
> > +if ( needs_ssbd_flip(current) )
> > +arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, 
> > NULL);
> > +
> >  return;
> >  }
> >  local_irq_enable();
> > diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> > index 40a80d5760..c4ccae6030 100644
> > --- a/xen/arch/arm/vsmc.c
> > +++ b/xen/arch/arm/vsmc.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -104,6 +105,23 @@ static bool handle_arch(struct cpu_user_regs *regs)
> >  if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
> >  ret = 0;
> >  break;
> > +case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
> > +switch ( get_ssbd_state() )
> > +{
> > +case ARM_SSBD_UNKNOWN:
> > +case ARM_SSBD_FORCE_DISABLE:
> > +break;
> > +
> > +case ARM_SSBD_RUNTIME:
> > +ret = ARM_SMCCC_SUCCESS;
> > +break;
> > +
> > +case ARM_SSBD_FORCE_ENABLE:
> > +case 

[Xen-devel] [ovmf baseline-only test] 74738: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74738 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74738/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 1e35fcc9ee8b6b991535d9d6731d0e04169b99c0
baseline version:
 ovmf 7ebad830d6ab61f0395f6f4bae4156664bbd8086

Last test of basis74733  2018-05-21 07:19:42 Z2 days
Testing same since74738  2018-05-23 13:49:23 Z0 days1 attempts


People who touched revisions under test:
  Ruiyu Ni 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 1e35fcc9ee8b6b991535d9d6731d0e04169b99c0
Author: Ruiyu Ni 
Date:   Wed May 9 17:36:06 2018 +0800

MdePkg/SmmPeriodicSmiLib: Get Periodic SMI Context More Robustly

The PeriodicSmiDispatchFunction() in SmmPeriodicSmiLib may assert
with "Bad CR signature".

Currently, the SetActivePeriodicSmiLibraryHandler() function
(invoked at the beginning of the PeriodicSmiDispatchFunction()
function) attempts to locate the PERIODIC_SMI_LIBRARY_HANDLER_CONTEXT
structure pointer for the current periodic SMI from a given
EFI_SMM_PERIODIC_TIMER_REGISTER_CONTEXT (RegiserContext) structure
pointer (using the CR macro).

The RegisterContext structure pointer passed to the
PeriodicSmiDispatchFunction() is assumed to point to the same
RegisterContext structure address given to the
SmmPeriodicTimerDispatch2 protocol Register() API in
PeriodicSmiEnable().

However, certain SmmPeriodicTimerDispatch2 implementation may copy
the RegisterContext to a local buffer and pass that address as the
context to PeriodicSmiDispatchFunction() in which case usage of the
CR macro to find the parent structure base fails.

The patch uses the LookupPeriodicSmiLibraryHandler() function to
find the PERIODIC_SMI_LIBRARY_HANDLER_CONTEXT structure pointer.
This works even in this scenario since the DispatchHandle returned
from the SmmPeriodicTimerDispatch2 Register() function uniquely
identifies that registration.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Michael D Kinney 
Reviewed-by: Liming Gao 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Using current is fairly expensive, so save up into a variable.
> 
> Signed-off-by: Julien Grall 

Good idea. I am curious to know actually how much this patch would save
but I am not going to ask you run the tests.

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/traps.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 020b0b8eef..b1546f6907 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct cpu_user_regs 
> *regs)
>  {
>  if ( guest_mode(regs) )
>  {
> +struct vcpu *v = current;
> +
>  /* If the guest has disabled the workaround, bring it back on. */
> -if ( needs_ssbd_flip(current) )
> +if ( needs_ssbd_flip(v) )
>  arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
>  
>  /*
> @@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct cpu_user_regs 
> *regs)
>   * but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE
>   * (alias of HCR.VA) is cleared to 0."
>   */
> -if ( current->arch.hcr_el2 & HCR_VA )
> -current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
> +if ( v->arch.hcr_el2 & HCR_VA )
> +v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
>  
>  #ifdef CONFIG_NEW_VGIC
>  /*
> @@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct 
> cpu_user_regs *regs)
>   * TODO: Investigate whether this is necessary to do on every
>   * trap and how it can be optimised.
>   */
> -vtimer_update_irqs(current);
> -vcpu_update_evtchn_irq(current);
> +vtimer_update_irqs(v);
> +vcpu_update_evtchn_irq(v);
>  #endif
>  
> -vgic_sync_from_lrs(current);
> +vgic_sync_from_lrs(v);
>  }
>  }
>  
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features"

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> At the moment, HARDEN_BRANCH_PREDICTOR is not in any section making
> impossible for the user to unselect it.
> 
> Also, it looks like we require to use 'expert = "y"' for showing the
> option in expert mode.
> 
> Signed-off-by: Julien Grall 

Very useful, thank you!

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/Kconfig | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 0e2d027060..4212c58171 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -83,6 +83,23 @@ config ARM_SSBD
>  
> If unsure, say Y.
>  
> +config HARDEN_BRANCH_PREDICTOR
> + bool "Harden the branch predictor against aliasing attacks" if EXPERT = 
> "y"
> + default y
> + help
> +   Speculation attacks against some high-performance processors rely on
> +   being able to manipulate the branch predictor for a victim context by
> +   executing aliasing branches in the attacker context.  Such attacks
> +   can be partially mitigated against by clearing internal branch
> +   predictor state and limiting the prediction logic in some situations.
> +
> +   This config option will take CPU-specific actions to harden the
> +   branch predictor against aliasing attacks and may rely on specific
> +   instruction sequences or control bits being set by the system
> +   firmware.
> +
> +   If unsure, say Y.
> +
>  endmenu
>  
>  menu "ARM errata workaround via the alternative framework"
> @@ -197,23 +214,6 @@ config ARM64_ERRATUM_834220
>  
>  endmenu
>  
> -config HARDEN_BRANCH_PREDICTOR
> - bool "Harden the branch predictor against aliasing attacks" if EXPERT
> - default y
> - help
> -   Speculation attacks against some high-performance processors rely on
> -   being able to manipulate the branch predictor for a victim context by
> -   executing aliasing branches in the attacker context.  Such attacks
> -   can be partially mitigated against by clearing internal branch
> -   predictor state and limiting the prediction logic in some situations.
> -
> -   This config option will take CPU-specific actions to harden the
> -   branch predictor against aliasing attacks and may rely on specific
> -   instruction sequences or control bits being set by the system
> -   firmware.
> -
> -   If unsure, say Y.
> -
>  config ARM64_HARDEN_BRANCH_PREDICTOR
>  def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
>  
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 

> ---
>  xen/include/asm-arm/smccc.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index a6804cec99..74c13f8419 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -254,9 +254,9 @@ struct arm_smccc_res {
>  
>  #define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
>  ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> -  ARM_SMCCC_CONV_32,\
> -  ARM_SMCCC_OWNER_ARCH, \
> -  0x8000)
> +   ARM_SMCCC_CONV_32,   \
> +   ARM_SMCCC_OWNER_ARCH,\
> +   0x8000)
>  
>  #define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
>  ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 09/13] xen/arm64: Add generic assembly macros

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Add assembly macros to simplify assembly code:
> - adr_cpu_info: Get the address to the current cpu_info structure
> - ldr_this_cpu: Load a per-cpu value
> 
> This is part of XSA-263.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/include/asm-arm/arm64/macros.h | 25 +
>  xen/include/asm-arm/macros.h   |  2 +-
>  2 files changed, 26 insertions(+), 1 deletion(-)
>  create mode 100644 xen/include/asm-arm/arm64/macros.h
> 
> diff --git a/xen/include/asm-arm/arm64/macros.h 
> b/xen/include/asm-arm/arm64/macros.h
> new file mode 100644
> index 00..9c5e676b37
> --- /dev/null
> +++ b/xen/include/asm-arm/arm64/macros.h
> @@ -0,0 +1,25 @@
> +#ifndef __ASM_ARM_ARM64_MACROS_H
> +#define __ASM_ARM_ARM64_MACROS_H
> +
> +/*
> + * @dst: Result of get_cpu_info()
> + */
> +.macro  adr_cpu_info, dst
> +add \dst, sp, #STACK_SIZE
> +and \dst, \dst, #~(STACK_SIZE - 1)
> +sub \dst, \dst, #CPUINFO_sizeof
> +.endm
> +
> +/*
> + * @dst: Result of READ_ONCE(per_cpu(sym, smp_processor_id()))
> + * @sym: The name of the per-cpu variable
> + * @tmp: scratch register
> + */
> +.macro  ldr_this_cpu, dst, sym, tmp
> +ldr \dst, =per_cpu__\sym
> +mrs \tmp, tpidr_el2
> +ldr \dst, [\dst, \tmp]
> +.endm
> +
> +#endif /* __ASM_ARM_ARM64_MACROS_H */
> +
> diff --git a/xen/include/asm-arm/macros.h b/xen/include/asm-arm/macros.h
> index 5d837cb38b..1d4bb41d15 100644
> --- a/xen/include/asm-arm/macros.h
> +++ b/xen/include/asm-arm/macros.h
> @@ -8,7 +8,7 @@
>  #if defined (CONFIG_ARM_32)
>  # include 
>  #elif defined(CONFIG_ARM_64)
> -/* No specific ARM64 macros for now */
> +# include 
>  #else
>  # error "unknown ARM variant"
>  #endif
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
> state of the workaround per-vCPU. The field 'pad' in cpu_info is now
> repurposed to store flags easily accessible in assembly.
> 
> As the hypervisor will always run with the workaround enabled, we may
> need to enable (on guest exit) or disable (on guest entry) the
> workaround.
> 
> A follow-up patch will add fastpath for the workaround for arm64 guests.
> 
> This is part of XSA-263.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/domain.c |  8 
>  xen/arch/arm/traps.c  | 20 
>  xen/arch/arm/vsmc.c   | 37 +
>  xen/include/asm-arm/current.h |  6 +-
>  4 files changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index e7b33e92fb..9168195a9c 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -21,6 +21,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -575,6 +576,13 @@ int vcpu_initialise(struct vcpu *v)
>  if ( (rc = vcpu_vtimer_init(v)) != 0 )
>  goto fail;
>  
> +/*
> + * The workaround 2 (i.e SSBD mitigation) is enabled by default if
> + * supported.
> + */
> +if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
> +v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
> +
>  return rc;
>  
>  fail:
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5c18e918b0..020b0b8eef 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2011,10 +2011,23 @@ inject_abt:
>  inject_iabt_exception(regs, gva, hsr.len);
>  }
>  
> +static inline bool needs_ssbd_flip(struct vcpu *v)
> +{
> +if ( !check_workaround_ssbd() )
> +return false;

Why not check on get_ssbd_state() == ARM_SSBD_RUNTIME?  I am confused on
when is the right time to use the cpu capability check
(check_workaround_ssbd), when is the right time to call get_ssbd_state()
and when is the right time to call cpu_require_ssbd_mitigation().


> +return !((v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
> + cpu_require_ssbd_mitigation());

It looks like this won't do as intended when v->arch.cpu_info->flags = 0
and cpu_require_ssbd_mitigation() returns false, am I right?

Maybe needs_ssbd_flip() should be implemented as follows:

  return get_ssbd_state() == ARM_SSBD_RUNTIME &&
!(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)


> +}
> +
>  static void enter_hypervisor_head(struct cpu_user_regs *regs)
>  {
>  if ( guest_mode(regs) )
>  {
> +/* If the guest has disabled the workaround, bring it back on. */
> +if ( needs_ssbd_flip(current) )
> +arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> +
>  /*
>   * If we pended a virtual abort, preserve it until it gets cleared.
>   * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details,
> @@ -2260,6 +2273,13 @@ void leave_hypervisor_tail(void)
>   */
>  SYNCHRONIZE_SERROR(SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT);
>  
> +/*
> + * The hypervisor runs with the workaround always present.
> + * If the guest wants it disabled, so be it...
> + */
> +if ( needs_ssbd_flip(current) )
> +arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> +
>  return;
>  }
>  local_irq_enable();
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 40a80d5760..c4ccae6030 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -104,6 +105,23 @@ static bool handle_arch(struct cpu_user_regs *regs)
>  if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
>  ret = 0;
>  break;
> +case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
> +switch ( get_ssbd_state() )
> +{
> +case ARM_SSBD_UNKNOWN:
> +case ARM_SSBD_FORCE_DISABLE:
> +break;
> +
> +case ARM_SSBD_RUNTIME:
> +ret = ARM_SMCCC_SUCCESS;
> +break;
> +
> +case ARM_SSBD_FORCE_ENABLE:
> +case ARM_SSBD_MITIGATED:
> +ret = ARM_SMCCC_NOT_REQUIRED;
> +break;
> +}
> +break;
>  }
>  
>  set_user_reg(regs, 0, ret);
> @@ -114,6 +132,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
>  case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
>  /* No return value */
>  return true;
> +
> +case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
> +{
> +bool enable = (uint32_t)get_user_reg(regs, 1);
> +
> +/*
> + * ARM_WORKAROUND_2_FID should 

Re: [Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> +extern enum ssbd_state ssbd_state;
> +
> +static inline enum ssbd_state get_ssbd_state(void)
> +{
> +return ssbd_state;
> +}
> +
>  DECLARE_PER_CPU(register_t, ssbd_callback_required);
>  
>  static inline bool cpu_require_ssbd_mitigation(void)
> @@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
>  return false;
>  }
>  
> +static inline enum ssbd_state get_sbdd_state(void)

The function name is mispelled


> +{
> +return ARM_SSBD_UNKNOWN;
> +}
> +
>  #endif


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 23/27] x86/modules: Adapt module loading for PIE support

[Randy Dunlap]

On 05/23/2018 03:01 PM, Thomas Garnier wrote:
> On Wed, May 23, 2018 at 2:27 PM Randy Dunlap  wrote:
> 
>> Hi,
> 
>> (for several patches in this series:)
>> The commit message is confusing.  See below.
> 
> Thanks for the edits, I will change the different commit messages.
> 
> 
> 
>> On 05/23/2018 12:54 PM, Thomas Garnier wrote:
>>> Adapt module loading to support PIE relocations. Generate dynamic GOT if
>>> a symbol requires it but no entry exist in the kernel GOT.
> 
>>  exists
> 
>>>
>>> Position Independent Executable (PIE) support will allow to extended the
> 
>>  will allow us to extend
> the
> 
>>> KASLR randomization range below the -2G memory limit.
> 
>> Does that say "below th negative 2G memory limit"?
>> I don't get it.
> 
> Yes, below 0x8000 basically. I think I will just say that.

Yes, please, that's much better.

> 
> 
>>>
>>> Signed-off-by: Thomas Garnier 
>>> ---
>>>  arch/x86/Makefile   |   4 +
>>>  arch/x86/include/asm/module.h   |  11 ++
>>>  arch/x86/include/asm/sections.h |   4 +
>>>  arch/x86/kernel/module.c| 181 +++-
>>>  arch/x86/kernel/module.lds  |   3 +
>>>  5 files changed, 198 insertions(+), 5 deletions(-)
>>>  create mode 100644 arch/x86/kernel/module.lds
> 
> 
>> Thanks,
>> --
>> ~Randy
> 
> 
> 


-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] MSR_SPEC_CTRL intercept

[Andrew Cooper]

On 23/05/2018 23:53, Boris Ostrovsky wrote:
> On 05/23/2018 06:34 PM, Andrew Cooper wrote:
>> On 23/05/2018 23:27, Boris Ostrovsky wrote:
>>> On 05/23/2018 06:09 PM, Andrew Cooper wrote:
 On 23/05/2018 22:59, Boris Ostrovsky wrote:
> On 05/23/2018 05:49 PM, Andrew Cooper wrote:
>> On 23/05/2018 22:40, Boris Ostrovsky wrote:
>>> Looking at vmx_cpuid_policy_changed():
>>>
>>>
>>>    if ( cp->feat.ibrsb )
>>>     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>>>     else
>>>     vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>>>
>>>
>>> Is there a reason why we are not checking cp->feat.ssbd as well?
>> Yes.  Read the final hunk of
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef
> SSBD implies IBRS --- yes, that's true. But not the other way around, no?
 That's not the way the dependency logic works.  That hunk says "if you
 haven't got IBRSB, then you don't have STIBP or SSBD either".
>>> I guess my actual question is --- If you have IBRSB but not SSBD (which
>>> is what we have today), do we want to intercept the access and screen
>>> for the guest writing the SSBD bit?
>> What would that achieve in practice?  TBF, I did start coding in the way
>> you suggest, but came to the conclusion that it was a pointless waste.
>>
>> Conceptually, being able to use the SSBD bit even if you can't see it in
>> CPUID is no different to "knowning" that certain instructions are
>> implemented in the pipeline and using them anyway.  Hiding the AES CPUID
>> bit doesn't prevent the pipeline from executing the AES instructions if
>> it encountered them.
>>
>> Furthermore, MSR_SPEC_CTRL is a frequently written MSR used in privilege
>> entry/exit points - Intercepting slows your VM down massively.
>
> Oh, right. I was thinking about catching a write to the unadvertised
> SSBD bit but I  guess it doesn't buy us anything.

Indeed.  Doing so would allow you to always raise a #GP fault, but the
CPUID bit being clear means that the bit has reserved/undefined
behaviour.  It doesn't mean that a #GP fault will definitely occur if
you play with it.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] MSR_SPEC_CTRL intercept

[Boris Ostrovsky]

On 05/23/2018 06:34 PM, Andrew Cooper wrote:
> On 23/05/2018 23:27, Boris Ostrovsky wrote:
>> On 05/23/2018 06:09 PM, Andrew Cooper wrote:
>>> On 23/05/2018 22:59, Boris Ostrovsky wrote:
 On 05/23/2018 05:49 PM, Andrew Cooper wrote:
> On 23/05/2018 22:40, Boris Ostrovsky wrote:
>> Looking at vmx_cpuid_policy_changed():
>>
>>
>>    if ( cp->feat.ibrsb )
>>     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>>     else
>>     vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>>
>>
>> Is there a reason why we are not checking cp->feat.ssbd as well?
> Yes.  Read the final hunk of
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef
 SSBD implies IBRS --- yes, that's true. But not the other way around, no?
>>> That's not the way the dependency logic works.  That hunk says "if you
>>> haven't got IBRSB, then you don't have STIBP or SSBD either".
>> I guess my actual question is --- If you have IBRSB but not SSBD (which
>> is what we have today), do we want to intercept the access and screen
>> for the guest writing the SSBD bit?
> What would that achieve in practice?  TBF, I did start coding in the way
> you suggest, but came to the conclusion that it was a pointless waste.
>
> Conceptually, being able to use the SSBD bit even if you can't see it in
> CPUID is no different to "knowning" that certain instructions are
> implemented in the pipeline and using them anyway.  Hiding the AES CPUID
> bit doesn't prevent the pipeline from executing the AES instructions if
> it encountered them.
>
> Furthermore, MSR_SPEC_CTRL is a frequently written MSR used in privilege
> entry/exit points - Intercepting slows your VM down massively.


Oh, right. I was thinking about catching a write to the unadvertised
SSBD bit but I  guess it doesn't buy us anything.


-boris


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

[Joe Perches]

On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
> On 5/23/18 2:05 PM, Joe Perches wrote:
> > Convert the S_ symbolic permissions to their octal equivalents as
> > using octal and not symbolic permissions is preferred by many as more
> > readable.
> > 
> > see: https://lkml.org/lkml/2016/8/2/1945
> > 
> > Done with automated conversion via:
> > $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> > 
> > Miscellanea:
> > 
> > o Wrapped modified multi-line calls to a single line where appropriate
> > o Realign modified multi-line calls to open parenthesis
> 
> Honestly, I see this as pretty needless churn.

btw:

There is currently a mixture of symbolic and octal
permissions uses in block and drivers/block

ie: 94 octal and 146 symbolic uses.

If this is applied, all would become octal.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> On a system where the firmware implements ARCH_WORKAROUND_2, it may be
> useful to either permanently enable or disable the workaround for cases
> where the user decides that they'd rather not get a trap overhead, and
> keep the mitigation permanently on or off instead of switching it on
> exception entry/exit.
> 
> In any case, default to mitigation being enabled.
> 
> At the same time provide a accessor to know the state of the mitigation.
> 
> SIgned-off-by: Julien Grall 
> ---
>  docs/misc/xen-command-line.markdown |  18 ++
>  xen/arch/arm/cpuerrata.c| 115 
> 
>  xen/include/asm-arm/cpuerrata.h |  21 +++
>  xen/include/asm-arm/smccc.h |   1 +
>  4 files changed, 144 insertions(+), 11 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 8712a833a2..962028b6ed 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout 
> of 670ms. Any number
>  is being interpreted as a custom timeout in milliseconds. Zero or boolean
>  false disable the quirk workaround, which is also the default.
>  
> +### spec-ctrl (Arm)
> +> `= List of [ ssbd=force-disable|runtime|force-enable ]`

Why a list? Shouldn't it be one or the other?

> +Controls for speculative execution sidechannel mitigations.
> +
> +The option `ssbd=` is used to control the state of Speculative Store
> +Bypass Disable (SSBD) mitigation.
> +
> +* `ssbd=force-disable` will keep the mitigation permanently off. The guest
> +will not be able to control the state of the mitigation.
> +* `ssbd=runtime` will always turn on the mitigation when running in the
> +hypervisor context. The guest will be to turn on/off the mitigation for
> +itself by using the firmware interface ARCH\_WORKAROUND\_2.
> +* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
> +not be able to control the state of the mitigation.
> +
> +By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
> +
>  ### spec-ctrl (x86)
>  > `= List of [ , xen=, {pv,hvm,msr-sc,rsb}=,
>  >  bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}= ]`
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index bcea2eb6e5..f921721a66 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
>  
>  #ifdef CONFIG_ARM_SSBD
>  
> +enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
> +
> +static int __init parse_spec_ctrl(const char *s)
> +{
> +const char *ss;
> +int rc = 0;
> +
> +do {
> +ss = strchr(s, ',');
> +if ( !ss )
> +ss = strchr(s, '\0');

It doesn't look like it is necessary to parse ',' at all. I would remove
the while loop too.


> +if ( !strncmp(s, "ssbd=", 5) )
> +{
> +s += 5;
> +
> +if ( !strncmp(s, "force-disable", ss - s) )
> +ssbd_state = ARM_SSBD_FORCE_DISABLE;
> +else if ( !strncmp(s, "runtime", ss - s) )
> +ssbd_state = ARM_SSBD_RUNTIME;
> +else if ( !strncmp(s, "force-enable", ss - s) )
> +ssbd_state = ARM_SSBD_FORCE_ENABLE;
> +else
> +rc = -EINVAL;
> +}
> +else
> +rc = -EINVAL;
> +
> +s = ss + 1;
> +} while ( *ss );
> +
> +return rc;
> +}
> +custom_param("spec-ctrl", parse_spec_ctrl);
> +
>  /*
>   * Assembly code may use the variable directly, so we need to make sure
>   * it fits in a register.
> @@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t, 
> ssbd_callback_required);
>  static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
>  {
>  struct arm_smccc_res res;
> -bool supported = true;
> +bool required = true;

Please avoid this renaming. Choose one name or the other from the start.


>  if ( smccc_ver < SMCCC_VERSION(1, 1) )
>  return false;
>  
> -/*
> - * The probe function return value is either negative (unsupported
> - * or mitigated), positive (unaffected), or zero (requires
> - * mitigation). We only need to do anything in the last case.
> - */

I would keep the comment


>  arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
>ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
> -if ( (int)res.a0 != 0 )
> -supported = false;
>  
> -if ( supported )
> -this_cpu(ssbd_callback_required) = 1;
> +switch ( (int)res.a0 )

Please introduce this switch in the previous patch. But it makes sense
to add the ssbd_state variable in this patch.


> +{
> +case ARM_SMCCC_NOT_SUPPORTED:
> +ssbd_state = ARM_SSBD_UNKNOWN;
> +return false;
> +
> +case ARM_SMCCC_NOT_REQUIRED:
> +ssbd_state = 

Re: [Xen-devel] MSR_SPEC_CTRL intercept

[Andrew Cooper]

On 23/05/2018 23:27, Boris Ostrovsky wrote:
> On 05/23/2018 06:09 PM, Andrew Cooper wrote:
>> On 23/05/2018 22:59, Boris Ostrovsky wrote:
>>> On 05/23/2018 05:49 PM, Andrew Cooper wrote:
 On 23/05/2018 22:40, Boris Ostrovsky wrote:
> Looking at vmx_cpuid_policy_changed():
>
>
>    if ( cp->feat.ibrsb )
>     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>     else
>     vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>
>
> Is there a reason why we are not checking cp->feat.ssbd as well?
 Yes.  Read the final hunk of
 http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef
>>> SSBD implies IBRS --- yes, that's true. But not the other way around, no?
>> That's not the way the dependency logic works.  That hunk says "if you
>> haven't got IBRSB, then you don't have STIBP or SSBD either".
> I guess my actual question is --- If you have IBRSB but not SSBD (which
> is what we have today), do we want to intercept the access and screen
> for the guest writing the SSBD bit?

What would that achieve in practice?  TBF, I did start coding in the way
you suggest, but came to the conclusion that it was a pointless waste.

Conceptually, being able to use the SSBD bit even if you can't see it in
CPUID is no different to "knowning" that certain instructions are
implemented in the pipeline and using them anyway.  Hiding the AES CPUID
bit doesn't prevent the pipeline from executing the AES instructions if
it encountered them.

Furthermore, MSR_SPEC_CTRL is a frequently written MSR used in privilege
entry/exit points - Intercepting slows your VM down massively.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing

[Julien Grall]

Hi,

On 05/23/2018 10:57 PM, Stefano Stabellini wrote:

On Tue, 22 May 2018, Julien Grall wrote:

As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
mechanism for detecting the SSBD mitigation.

A new capability is also allocated for that purpose, and a config
option.

This is part of XSA-263.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/Kconfig | 10 ++
  xen/arch/arm/cpuerrata.c | 39 +++
  xen/include/asm-arm/cpuerrata.h  | 21 +
  xen/include/asm-arm/cpufeature.h |  3 ++-
  xen/include/asm-arm/smccc.h  |  6 ++
  5 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c635..0e2d027060 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
  Allows a guest to use SBSA Generic UART as a console. The
  SBSA Generic UART implements a subset of ARM PL011 UART.
  
+config ARM_SSBD

+   bool "Speculative Store Bypass Disable" if EXPERT = "y"
+   depends on HAS_ALTERNATIVE
+   default y
+   help
+ This enables mitigation of bypassing of previous stores by speculative
+ loads.


I would add a reference to spectre v4. What do you think of:

   This enables the mitigation of Spectre v4 attacks based on bypassing
   of previous memory stores by speculative loads.


Well, the real name is SSBD (Speculative Store Bypass Disable). AFAIK, 
Spectre only refers to variant 1 and 2 so far. This one has no fancy 
name and the specifications is using SSBD.



+ If unsure, say Y.
+
  endmenu
  
  menu "ARM errata workaround via the alternative framework"

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..bcea2eb6e5 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -235,6 +235,39 @@ static int enable_ic_inv_hardening(void *data)
  
  #endif
  
+#ifdef CONFIG_ARM_SSBD

+
+/*
+ * Assembly code may use the variable directly, so we need to make sure
+ * it fits in a register.
+ */
+DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
+
+static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+bool supported = true;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+/*
+ * The probe function return value is either negative (unsupported
+ * or mitigated), positive (unaffected), or zero (requires
+ * mitigation). We only need to do anything in the last case.
+ */
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
+if ( (int)res.a0 != 0 )
+supported = false;
+
+if ( supported )
+this_cpu(ssbd_callback_required) = 1;
+
+return supported;
+}
+#endif
+
  #define MIDR_RANGE(model, min, max) \
  .matches = is_affected_midr_range,  \
  .midr_model = model,\
@@ -336,6 +369,12 @@ static const struct arm_cpu_capabilities arm_errata[] = {
  .enable = enable_ic_inv_hardening,
  },
  #endif
+#ifdef CONFIG_ARM_SSBD
+{
+.capability = ARM_SSBD,
+.matches = has_ssbd_mitigation,
+},
+#endif
  {},
  };
  
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h

index 4e45b237c8..e628d3ff56 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void)  
   \
  
  CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)

  CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
  
  #undef CHECK_WORKAROUND_HELPER
  
+#ifdef CONFIG_ARM_SSBD

+
+#include 
+
+DECLARE_PER_CPU(register_t, ssbd_callback_required);


It is becoming more common to have per-cpu capabilities and workarounds
(or at least per MPIDR).


Really? This is the first place where we need an ad-hoc boolean per-CPU. 
For the hardening branch predictor, we have to store the vector pointer.



Instead of adding this add-hoc variable, should
we make cpu_hwcaps per-cpu, then implement this check with
cpus_have_cap (that would become per-cpu as well)?

It looks like the code would be simpler.


I don't see any benefits for that. Most of the workaround/features are 
platform wide because they either use alternative or set/clear a bit in 
the system registers.


Furthermore, as I wrote above the declaration, this is going to be used 
in assembly code and we need something that can be tested in the less 
possible number of instructions because The smccc function 
ARM_ARCH_WORKAROUND_2 is going to be called very often.


Lastly, after the next patch, ssbd_callback_required and ARM_SSBD have 
different meaning. The former indicates that runtime mitigation is 
required, while the 

Re: [Xen-devel] MSR_SPEC_CTRL intercept

[Boris Ostrovsky]

On 05/23/2018 06:09 PM, Andrew Cooper wrote:
> On 23/05/2018 22:59, Boris Ostrovsky wrote:
>> On 05/23/2018 05:49 PM, Andrew Cooper wrote:
>>> On 23/05/2018 22:40, Boris Ostrovsky wrote:
 Looking at vmx_cpuid_policy_changed():


    if ( cp->feat.ibrsb )
     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
     else
     vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);


 Is there a reason why we are not checking cp->feat.ssbd as well?
>>> Yes.  Read the final hunk of
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef
>> SSBD implies IBRS --- yes, that's true. But not the other way around, no?
> That's not the way the dependency logic works.  That hunk says "if you
> haven't got IBRSB, then you don't have STIBP or SSBD either".

I guess my actual question is --- If you have IBRSB but not SSBD (which
is what we have today), do we want to intercept the access and screen
for the guest writing the SSBD bit?

-boris

>
> It is, as documented, not completely strictly true (according to the
> latest revision of the spec), but is there deliberately to simply so we
> don't give the guest implausible configurations.  There is not a
> processor with STIBP but without IBRSB, nor is there one with SSBD
> without STIBP or IBRSB, and it is unlikely that future processors would
> change this arrangement.
>
> A side effect of prohibiting the implausible configurations is that the
> logic in Xen is much more simple.
>
> ~Andrew


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.6-testing baseline-only test] 74736: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74736 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74736/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-121 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 74719
 test-xtf-amd64-amd64-1 36 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 74719
 test-xtf-amd64-amd64-149 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 74719
 test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail REGR. vs. 74719
 test-amd64-amd64-xl-qemuu-win10-i386 16 guest-localmigrate/x10 fail REGR. vs. 
74719

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 74719
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail   like 74719
 test-armhf-armhf-libvirt 12 guest-start  fail   like 74719
 test-armhf-armhf-xl-xsm  12 guest-start  fail   like 74719
 test-armhf-armhf-xl-multivcpu 12 guest-start  fail  like 74719
 test-armhf-armhf-xl-midway   12 guest-start  fail   like 74719
 test-armhf-armhf-xl-credit2  12 guest-start  fail   like 74719
 test-armhf-armhf-xl  12 guest-start  fail   like 74719
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail like 74719
 test-armhf-armhf-xl-rtds 12 guest-start  fail   like 74719
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74719
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 74719
 test-armhf-armhf-xl-vhd  10 debian-di-installfail   like 74719
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 74719
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail   like 74719
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 74719
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 74719
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  12b9fca6046741ffcda9eb3320f47093ed5d9ef0
baseline version:
 xen  6a74f4e31dc28fb0d5c9e56b54d4b2aaf9b46bbe

Last test of basis74719  2018-05-16 01:17:41 Z7 days
Testing same since74736  2018-05-23 10:17:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   

Re: [Xen-devel] MSR_SPEC_CTRL intercept

[Andrew Cooper]

On 23/05/2018 22:59, Boris Ostrovsky wrote:
> On 05/23/2018 05:49 PM, Andrew Cooper wrote:
>> On 23/05/2018 22:40, Boris Ostrovsky wrote:
>>> Looking at vmx_cpuid_policy_changed():
>>>
>>>
>>>    if ( cp->feat.ibrsb )
>>>     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>>>     else
>>>     vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>>>
>>>
>>> Is there a reason why we are not checking cp->feat.ssbd as well?
>> Yes.  Read the final hunk of
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef
> SSBD implies IBRS --- yes, that's true. But not the other way around, no?

That's not the way the dependency logic works.  That hunk says "if you
haven't got IBRSB, then you don't have STIBP or SSBD either".

It is, as documented, not completely strictly true (according to the
latest revision of the spec), but is there deliberately to simply so we
don't give the guest implausible configurations.  There is not a
processor with STIBP but without IBRSB, nor is there one with SSBD
without STIBP or IBRSB, and it is unlikely that future processors would
change this arrangement.

A side effect of prohibiting the implausible configurations is that the
logic in Xen is much more simple.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 23/27] x86/modules: Adapt module loading for PIE support

[Thomas Garnier]

On Wed, May 23, 2018 at 2:27 PM Randy Dunlap  wrote:

> Hi,

> (for several patches in this series:)
> The commit message is confusing.  See below.

Thanks for the edits, I will change the different commit messages.



> On 05/23/2018 12:54 PM, Thomas Garnier wrote:
> > Adapt module loading to support PIE relocations. Generate dynamic GOT if
> > a symbol requires it but no entry exist in the kernel GOT.

>  exists

> >
> > Position Independent Executable (PIE) support will allow to extended the

>  will allow us to extend
the

> > KASLR randomization range below the -2G memory limit.

> Does that say "below th negative 2G memory limit"?
> I don't get it.

Yes, below 0x8000 basically. I think I will just say that.



> >
> > Signed-off-by: Thomas Garnier 
> > ---
> >  arch/x86/Makefile   |   4 +
> >  arch/x86/include/asm/module.h   |  11 ++
> >  arch/x86/include/asm/sections.h |   4 +
> >  arch/x86/kernel/module.c| 181 +++-
> >  arch/x86/kernel/module.lds  |   3 +
> >  5 files changed, 198 insertions(+), 5 deletions(-)
> >  create mode 100644 arch/x86/kernel/module.lds


> Thanks,
> --
> ~Randy



-- 
Thomas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
> mechanism for detecting the SSBD mitigation.
> 
> A new capability is also allocated for that purpose, and a config
> option.
> 
> This is part of XSA-263.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/Kconfig | 10 ++
>  xen/arch/arm/cpuerrata.c | 39 +++
>  xen/include/asm-arm/cpuerrata.h  | 21 +
>  xen/include/asm-arm/cpufeature.h |  3 ++-
>  xen/include/asm-arm/smccc.h  |  6 ++
>  5 files changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 8174c0c635..0e2d027060 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
> Allows a guest to use SBSA Generic UART as a console. The
> SBSA Generic UART implements a subset of ARM PL011 UART.
>  
> +config ARM_SSBD
> + bool "Speculative Store Bypass Disable" if EXPERT = "y"
> + depends on HAS_ALTERNATIVE
> + default y
> + help
> +   This enables mitigation of bypassing of previous stores by speculative
> +   loads.

I would add a reference to spectre v4. What do you think of:

  This enables the mitigation of Spectre v4 attacks based on bypassing
  of previous memory stores by speculative loads.


> +   If unsure, say Y.
> +
>  endmenu
>  
>  menu "ARM errata workaround via the alternative framework"
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 1baa20654b..bcea2eb6e5 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -235,6 +235,39 @@ static int enable_ic_inv_hardening(void *data)
>  
>  #endif
>  
> +#ifdef CONFIG_ARM_SSBD
> +
> +/*
> + * Assembly code may use the variable directly, so we need to make sure
> + * it fits in a register.
> + */
> +DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
> +
> +static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
> +{
> +struct arm_smccc_res res;
> +bool supported = true;
> +
> +if ( smccc_ver < SMCCC_VERSION(1, 1) )
> +return false;
> +
> +/*
> + * The probe function return value is either negative (unsupported
> + * or mitigated), positive (unaffected), or zero (requires
> + * mitigation). We only need to do anything in the last case.
> + */
> +arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> +  ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
> +if ( (int)res.a0 != 0 )
> +supported = false;
> +
> +if ( supported )
> +this_cpu(ssbd_callback_required) = 1;
> +
> +return supported;
> +}
> +#endif
> +
>  #define MIDR_RANGE(model, min, max) \
>  .matches = is_affected_midr_range,  \
>  .midr_model = model,\
> @@ -336,6 +369,12 @@ static const struct arm_cpu_capabilities arm_errata[] = {
>  .enable = enable_ic_inv_hardening,
>  },
>  #endif
> +#ifdef CONFIG_ARM_SSBD
> +{
> +.capability = ARM_SSBD,
> +.matches = has_ssbd_mitigation,
> +},
> +#endif
>  {},
>  };
>  
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> index 4e45b237c8..e628d3ff56 100644
> --- a/xen/include/asm-arm/cpuerrata.h
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void)
>  \
>  
>  CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
>  CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
> +CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
>  
>  #undef CHECK_WORKAROUND_HELPER
>  
> +#ifdef CONFIG_ARM_SSBD
> +
> +#include 
> +
> +DECLARE_PER_CPU(register_t, ssbd_callback_required);

It is becoming more common to have per-cpu capabilities and workarounds
(or at least per MPIDR). Instead of adding this add-hoc variable, should
we make cpu_hwcaps per-cpu, then implement this check with
cpus_have_cap (that would become per-cpu as well)?

It looks like the code would be simpler.


> +static inline bool cpu_require_ssbd_mitigation(void)
> +{
> +return this_cpu(ssbd_callback_required);
> +}
> +
> +#else
> +
> +static inline bool cpu_require_ssbd_mitigation(void)
> +{
> +return false;
> +}
>
> +#endif
> +
>  #endif /* __ARM_CPUERRATA_H__ */
>  /*
>   * Local variables:
> diff --git a/xen/include/asm-arm/cpufeature.h 
> b/xen/include/asm-arm/cpufeature.h
> index e557a095af..2a5c075d3b 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -43,8 +43,9 @@
>  #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
>  #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
>  #define ARM_HARDEN_BRANCH_PREDICTOR 7
> +#define ARM_SSBD 8
>  
> -#define ARM_NCAPS   8
> +#define ARM_NCAPS   9
>  
>  #ifndef __ASSEMBLY__
>  
> diff --git 

Re: [Xen-devel] MSR_SPEC_CTRL intercept

[Boris Ostrovsky]

On 05/23/2018 05:49 PM, Andrew Cooper wrote:
> On 23/05/2018 22:40, Boris Ostrovsky wrote:
>> Looking at vmx_cpuid_policy_changed():
>>
>>
>>    if ( cp->feat.ibrsb )
>>     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>>     else
>>     vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>>
>>
>> Is there a reason why we are not checking cp->feat.ssbd as well?
> Yes.  Read the final hunk of
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef

SSBD implies IBRS --- yes, that's true. But not the other way around, no?

-boris

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-3.18 test] 123035: tolerable FAIL - PUSHED

[osstest service owner]

flight 123035 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123035/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 122965 pass in 123035
 test-armhf-armhf-xl-credit2  12 guest-start  fail in 122965 pass in 123035
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
122965
 test-armhf-armhf-xl  16 guest-start/debian.repeat  fail pass in 122965

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122565
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122565
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122565
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122565
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122565
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122565
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122565
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux7eac0d47b74e08e7060e293527524986554b
baseline version:
 linux6d05aadb69916b7e6595658fd57821219d16f2e6

Last test of basis   122565  2018-05-02 15:10:45 Z   21 days
Testing same since   122884  2018-05-16 16:40:24 Z7 days3 attempts

Re: [Xen-devel] MSR_SPEC_CTRL intercept

[Andrew Cooper]

On 23/05/2018 22:40, Boris Ostrovsky wrote:
> Looking at vmx_cpuid_policy_changed():
>
>
>    if ( cp->feat.ibrsb )
>     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>     else
>     vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
>
>
> Is there a reason why we are not checking cp->feat.ssbd as well?

Yes.  Read the final hunk of
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] MSR_SPEC_CTRL intercept

[Boris Ostrovsky]

Looking at vmx_cpuid_policy_changed():


   if ( cp->feat.ibrsb )
    vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
    else
    vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);


Is there a reason why we are not checking cp->feat.ssbd as well?


-boris

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Some errata will rely on the SMCCC version which is detected by
> psci_init().
> 
> This is part of XSA-263.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/setup.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 1d6f6bf37e..ac93de4786 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -171,8 +171,6 @@ static void __init processor_id(void)
>  }
>  
>  processor_setup();
> -
> -check_local_cpu_errata();
>  }
>  
>  void dt_unreserved_regions(paddr_t s, paddr_t e,
> @@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset,
>  printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
>  nr_cpu_ids = cpus;
>  
> +/*
> + * Some errata relies on SMCCC version which is detected by psci_init()
> + * (called from smp_init_cpus()).
> + */
> +check_local_cpu_errata();
> +
>  init_xen_time();
>  
>  gic_init();
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/13] xen/arm64: entry: Use named label in guest_sync

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> This will improve readability for future changes.
> 
> This is part of XSA-263.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/arm64/entry.S | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index ffa9a1c492..e2344e565f 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -226,11 +226,11 @@ guest_sync:
>  mrs x1, esr_el2
>  lsr x1, x1, #HSR_EC_SHIFT   /* x1 = ESR_EL2.EC */
>  cmp x1, #HSR_EC_HVC64
> -b.ne1f  /* Not a HVC skip fastpath. 
> */
> +b.neguest_sync_slowpath /* Not a HVC skip fastpath. 
> */
>  
>  mrs x1, esr_el2
>  and x1, x1, #0x /* Check the immediate 
> [0:16] */
> -cbnzx1, 1f  /* should be 0 for HVC #0 */
> +cbnzx1, guest_sync_slowpath /* should be 0 for HVC #0 */
>  
>  /*
>   * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
> @@ -241,7 +241,7 @@ guest_sync:
>   * be encoded as an immediate for cmp.
>   */
>  eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
> -cbnzw0, 1f
> +cbnzw0, guest_sync_slowpath
>  
>  /*
>   * Clobber both x0 and x1 to prevent leakage. Note that thanks
> @@ -250,7 +250,7 @@ guest_sync:
>  mov x1, xzr
>  eret
>  
> -1:
> +guest_sync_slowpath:
>  /*
>   * x0/x1 may have been scratch by the fast path above, so avoid
>   * to save them.
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 23/27] x86/modules: Adapt module loading for PIE support

[Randy Dunlap]

Hi,

(for several patches in this series:)
The commit message is confusing.  See below.


On 05/23/2018 12:54 PM, Thomas Garnier wrote:
> Adapt module loading to support PIE relocations. Generate dynamic GOT if
> a symbol requires it but no entry exist in the kernel GOT.

exists

> 
> Position Independent Executable (PIE) support will allow to extended the

will allow us to extend the

> KASLR randomization range below the -2G memory limit.

Does that say "below th negative 2G memory limit"?
I don't get it.


> 
> Signed-off-by: Thomas Garnier 
> ---
>  arch/x86/Makefile   |   4 +
>  arch/x86/include/asm/module.h   |  11 ++
>  arch/x86/include/asm/sections.h |   4 +
>  arch/x86/kernel/module.c| 181 +++-
>  arch/x86/kernel/module.lds  |   3 +
>  5 files changed, 198 insertions(+), 5 deletions(-)
>  create mode 100644 arch/x86/kernel/module.lds


Thanks,
-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

[Jens Axboe]

On 5/23/18 2:05 PM, Joe Perches wrote:
> Convert the S_ symbolic permissions to their octal equivalents as
> using octal and not symbolic permissions is preferred by many as more
> readable.
> 
> see: https://lkml.org/lkml/2016/8/2/1945
> 
> Done with automated conversion via:
> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> 
> Miscellanea:
> 
> o Wrapped modified multi-line calls to a single line where appropriate
> o Realign modified multi-line calls to open parenthesis

Honestly, I see this as pretty needless churn.

-- 
Jens Axboe


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 16/27] compiler: Option to add PROVIDE_HIDDEN replacement for weak symbols

[Randy Dunlap]

On 05/23/2018 12:54 PM, Thomas Garnier wrote:
> Provide an option to have a PROVIDE_HIDDEN (linker script) entry for
> each weak symbol. This option solve an error in x86_64 where the linker

solves

> optimizes pie generate code to be non-pie because --emit-relocs was used

generated

> instead of -pie (to reduce dynamic relocations).
> 
> Signed-off-by: Thomas Garnier 
> ---
>  init/Kconfig|  7 +++
>  scripts/link-vmlinux.sh | 14 ++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 0fc3a58d9f2f..2866cca86b4a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1954,6 +1954,13 @@ config ASN1
> inform it as to what tags are to be expected in a stream and what
> functions to call on what tags.
>  
> +config WEAK_PROVIDE_HIDDEN
> + bool
> + help
> +   Generate linker script PROVIDE_HIDDEN entries for all weak symbols. It
> +   allows to prevent non-pie code being replaced by the linker if the

non-PIE

> +   emit-relocs option is used instead of pie (useful for x86_64 pie).

PIEPIE).

> +


-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

[Joe Perches]

Convert the S_ symbolic permissions to their octal equivalents as
using octal and not symbolic permissions is preferred by many as more
readable.

see: https://lkml.org/lkml/2016/8/2/1945

Done with automated conversion via:
$ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 

Miscellanea:

o Wrapped modified multi-line calls to a single line where appropriate
o Realign modified multi-line calls to open parenthesis

Signed-off-by: Joe Perches 
---
 block/blk-integrity.c   | 12 +++
 block/blk-mq-sysfs.c|  6 ++--
 block/blk-sysfs.c   | 68 ++---
 block/cfq-iosched.c |  2 +-
 block/deadline-iosched.c|  3 +-
 block/genhd.c   | 37 ++--
 block/mq-deadline.c |  3 +-
 block/partition-generic.c   | 22 ++--
 drivers/block/DAC960.c  |  3 +-
 drivers/block/aoe/aoeblk.c  | 10 +++---
 drivers/block/brd.c |  6 ++--
 drivers/block/drbd/drbd_debugfs.c   | 20 +--
 drivers/block/drbd/drbd_main.c  |  4 +--
 drivers/block/floppy.c  |  2 +-
 drivers/block/loop.c|  6 ++--
 drivers/block/mtip32xx/mtip32xx.c   | 11 +++---
 drivers/block/nbd.c |  2 +-
 drivers/block/null_blk.c| 30 
 drivers/block/pktcdvd.c |  4 +--
 drivers/block/rbd.c | 44 
 drivers/block/rsxx/core.c   |  6 ++--
 drivers/block/virtio_blk.c  |  6 ++--
 drivers/block/xen-blkback/blkback.c |  2 +-
 drivers/block/xen-blkback/xenbus.c  |  4 +--
 drivers/block/xen-blkfront.c|  7 ++--
 25 files changed, 156 insertions(+), 164 deletions(-)

diff --git a/block/blk-integrity.c b/block/blk-integrity.c
index feb30570eaf5..6121611e1316 100644
--- a/block/blk-integrity.c
+++ b/block/blk-integrity.c
@@ -333,34 +333,34 @@ static ssize_t integrity_device_show(struct blk_integrity 
*bi, char *page)
 }
 
 static struct integrity_sysfs_entry integrity_format_entry = {
-   .attr = { .name = "format", .mode = S_IRUGO },
+   .attr = { .name = "format", .mode = 0444 },
.show = integrity_format_show,
 };
 
 static struct integrity_sysfs_entry integrity_tag_size_entry = {
-   .attr = { .name = "tag_size", .mode = S_IRUGO },
+   .attr = { .name = "tag_size", .mode = 0444 },
.show = integrity_tag_size_show,
 };
 
 static struct integrity_sysfs_entry integrity_interval_entry = {
-   .attr = { .name = "protection_interval_bytes", .mode = S_IRUGO },
+   .attr = { .name = "protection_interval_bytes", .mode = 0444 },
.show = integrity_interval_show,
 };
 
 static struct integrity_sysfs_entry integrity_verify_entry = {
-   .attr = { .name = "read_verify", .mode = S_IRUGO | S_IWUSR },
+   .attr = { .name = "read_verify", .mode = 0644 },
.show = integrity_verify_show,
.store = integrity_verify_store,
 };
 
 static struct integrity_sysfs_entry integrity_generate_entry = {
-   .attr = { .name = "write_generate", .mode = S_IRUGO | S_IWUSR },
+   .attr = { .name = "write_generate", .mode = 0644 },
.show = integrity_generate_show,
.store = integrity_generate_store,
 };
 
 static struct integrity_sysfs_entry integrity_device_entry = {
-   .attr = { .name = "device_is_integrity_capable", .mode = S_IRUGO },
+   .attr = { .name = "device_is_integrity_capable", .mode = 0444 },
.show = integrity_device_show,
 };
 
diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c
index a54b4b070f1c..aafb44224c89 100644
--- a/block/blk-mq-sysfs.c
+++ b/block/blk-mq-sysfs.c
@@ -166,15 +166,15 @@ static struct attribute *default_ctx_attrs[] = {
 };
 
 static struct blk_mq_hw_ctx_sysfs_entry blk_mq_hw_sysfs_nr_tags = {
-   .attr = {.name = "nr_tags", .mode = S_IRUGO },
+   .attr = {.name = "nr_tags", .mode = 0444 },
.show = blk_mq_hw_sysfs_nr_tags_show,
 };
 static struct blk_mq_hw_ctx_sysfs_entry blk_mq_hw_sysfs_nr_reserved_tags = {
-   .attr = {.name = "nr_reserved_tags", .mode = S_IRUGO },
+   .attr = {.name = "nr_reserved_tags", .mode = 0444 },
.show = blk_mq_hw_sysfs_nr_reserved_tags_show,
 };
 static struct blk_mq_hw_ctx_sysfs_entry blk_mq_hw_sysfs_cpus = {
-   .attr = {.name = "cpu_list", .mode = S_IRUGO },
+   .attr = {.name = "cpu_list", .mode = 0444 },
.show = blk_mq_hw_sysfs_cpus_show,
 };
 
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index cae525b7aae6..31347e31daa3 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -502,187 +502,187 @@ static ssize_t queue_dax_show(struct request_queue *q, 
char *page)
 }
 
 static struct queue_sysfs_entry queue_requests_entry = {
-   .attr = {.name = "nr_requests", .mode = S_IRUGO | S_IWUSR },
+   .attr = {.name = "nr_requests", .mode = 0644 },
.show = queue_requests_show,
.store = 

[Xen-devel] [PATCH v3 22/27] x86/modules: Add option to start module section after kernel

[Thomas Garnier]

Add an option so the module section is just after the mapped kernel. It
will ensure position independent modules are always at the right
distance from the kernel and do not require mcmodule=large. It also
optimize the available size for modules by getting rid of the empty
space on kernel randomization range.

Signed-off-by: Thomas Garnier 
---
 Documentation/x86/x86_64/mm.txt | 3 +++
 arch/x86/Kconfig| 4 
 arch/x86/include/asm/pgtable_64_types.h | 6 ++
 arch/x86/kernel/head64.c| 5 -
 arch/x86/mm/dump_pagetables.c   | 3 ++-
 5 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 600bc2afa27d..e3810a1db74b 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -79,3 +79,6 @@ Their order is preserved but their base will be offset early 
at boot time.
 Be very careful vs. KASLR when changing anything here. The KASLR address
 range must not overlap with anything except the KASAN shadow area, which is
 correct as KASAN disables KASLR.
+
+If CONFIG_DYNAMIC_MODULE_BASE is enabled, the module section follows the end of
+the mapped kernel.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0fc2e981458d..28eb2b3757bf 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2199,6 +2199,10 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
 
   If unsure, leave at the default value.
 
+# Module section starts just after the end of the kernel module
+config DYNAMIC_MODULE_BASE
+   bool
+
 config X86_GLOBAL_STACKPROTECTOR
bool "Stack cookie using a global variable"
depends on CC_STACKPROTECTOR_AUTO
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index adb47552e6bb..3ab25b908879 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -7,6 +7,7 @@
 #ifndef __ASSEMBLY__
 #include 
 #include 
+#include 
 
 /*
  * These are used to make use of C type-checking..
@@ -126,7 +127,12 @@ extern unsigned int ptrs_per_p4d;
 
 #define VMALLOC_END(VMALLOC_START + (VMALLOC_SIZE_TB << 40) - 1)
 
+#ifdef CONFIG_DYNAMIC_MODULE_BASE
+#define MODULES_VADDR  ALIGN(((unsigned long)_end + PAGE_SIZE), 
PMD_SIZE)
+#else
 #define MODULES_VADDR  (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+#endif
+
 /* The module sections ends with the start of the fixmap */
 #define MODULES_END_AC(0xff00, UL)
 #define MODULES_LEN(MODULES_END - MODULES_VADDR)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index fa661fb97127..3a1ce822e1c0 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -394,12 +394,15 @@ asmlinkage __visible void __init x86_64_start_kernel(char 
* real_mode_data)
 * Build-time sanity checks on the kernel image and module
 * area mappings. (these are purely build-time and produce no code)
 */
+#ifndef CONFIG_DYNAMIC_MODULE_BASE
BUILD_BUG_ON(MODULES_VADDR < __START_KERNEL_map);
BUILD_BUG_ON(MODULES_VADDR - __START_KERNEL_map < KERNEL_IMAGE_SIZE);
-   BUILD_BUG_ON(MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
+   BUILD_BUG_ON(!IS_ENABLED(CONFIG_RANDOMIZE_BASE_LARGE) &&
+MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
BUILD_BUG_ON((__START_KERNEL_map & ~PMD_MASK) != 0);
BUILD_BUG_ON((MODULES_VADDR & ~PMD_MASK) != 0);
BUILD_BUG_ON(!(MODULES_VADDR > __START_KERNEL));
+#endif
MAYBE_BUILD_BUG_ON(!(((MODULES_END - 1) & PGDIR_MASK) ==
(__START_KERNEL & PGDIR_MASK)));
BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END);
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index cc7ff5957194..dca4098ce4fd 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -105,7 +105,7 @@ static struct addr_marker address_markers[] = {
[EFI_END_NR]= { EFI_VA_END, "EFI Runtime Services" 
},
 #endif
[HIGH_KERNEL_NR]= { __START_KERNEL_map, "High Kernel Mapping" },
-   [MODULES_VADDR_NR]  = { MODULES_VADDR,  "Modules" },
+   [MODULES_VADDR_NR]  = { 0/*MODULES_VADDR*/, "Modules" },
[MODULES_END_NR]= { MODULES_END,"End Modules" },
[FIXADDR_START_NR]  = { FIXADDR_START,  "Fixmap Area" },
[END_OF_SPACE_NR]   = { -1, NULL }
@@ -600,6 +600,7 @@ static int __init pt_dump_init(void)
address_markers[KASAN_SHADOW_START_NR].start_address = 
KASAN_SHADOW_START;
address_markers[KASAN_SHADOW_END_NR].start_address = KASAN_SHADOW_END;
 #endif
+   address_markers[MODULES_VADDR_NR].start_address = MODULES_VADDR;
 #endif
 #ifdef CONFIG_X86_32
address_markers[VMALLOC_START_NR].start_address = VMALLOC_START;
-- 

[Xen-devel] [PATCH v3 26/27] x86/relocs: Add option to generate 64-bit relocations

[Thomas Garnier]

The x86 relocation tool generates a list of 32-bit signed integers. There
was no need to use 64-bit integers because all addresses where above the 2G
top of the memory.

This change add a large-reloc option to generate 64-bit unsigned integers.
It can be used when the kernel plan to go below the top 2G and 32-bit
integers are not enough.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c| 60 +++---
 arch/x86/tools/relocs.h|  4 +--
 arch/x86/tools/relocs_common.c | 15 ++---
 3 files changed, 60 insertions(+), 19 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 29283ad3950f..a29eaac6 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -13,8 +13,14 @@
 
 static Elf_Ehdr ehdr;
 
+#if ELF_BITS == 64
+typedef uint64_t rel_off_t;
+#else
+typedef uint32_t rel_off_t;
+#endif
+
 struct relocs {
-   uint32_t*offset;
+   rel_off_t   *offset;
unsigned long   count;
unsigned long   size;
 };
@@ -685,7 +691,7 @@ static void print_absolute_relocs(void)
printf("\n");
 }
 
-static void add_reloc(struct relocs *r, uint32_t offset)
+static void add_reloc(struct relocs *r, rel_off_t offset)
 {
if (r->count == r->size) {
unsigned long newsize = r->size + 5;
@@ -1061,26 +1067,48 @@ static void sort_relocs(struct relocs *r)
qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs);
 }
 
-static int write32(uint32_t v, FILE *f)
+static int write32(rel_off_t rel, FILE *f)
 {
-   unsigned char buf[4];
+   unsigned char buf[sizeof(uint32_t)];
+   uint32_t v = (uint32_t)rel;
 
put_unaligned_le32(v, buf);
-   return fwrite(buf, 1, 4, f) == 4 ? 0 : -1;
+   return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
 }
 
-static int write32_as_text(uint32_t v, FILE *f)
+static int write32_as_text(rel_off_t rel, FILE *f)
 {
+   uint32_t v = (uint32_t)rel;
return fprintf(f, "\t.long 0x%08"PRIx32"\n", v) > 0 ? 0 : -1;
 }
 
-static void emit_relocs(int as_text, int use_real_mode)
+static int write64(rel_off_t rel, FILE *f)
+{
+   unsigned char buf[sizeof(uint64_t)];
+   uint64_t v = (uint64_t)rel;
+
+   put_unaligned_le64(v, buf);
+   return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
+}
+
+static int write64_as_text(rel_off_t rel, FILE *f)
+{
+   uint64_t v = (uint64_t)rel;
+   return fprintf(f, "\t.quad 0x%016"PRIx64"\n", v) > 0 ? 0 : -1;
+}
+
+static void emit_relocs(int as_text, int use_real_mode, int use_large_reloc)
 {
int i;
-   int (*write_reloc)(uint32_t, FILE *) = write32;
+   int (*write_reloc)(rel_off_t, FILE *);
int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
const char *symname);
 
+   if (use_large_reloc)
+   write_reloc = write64;
+   else
+   write_reloc = write32;
+
 #if ELF_BITS == 64
if (!use_real_mode)
do_reloc = do_reloc64;
@@ -1091,6 +1119,9 @@ static void emit_relocs(int as_text, int use_real_mode)
do_reloc = do_reloc32;
else
do_reloc = do_reloc_real;
+
+   /* Large relocations only for 64-bit */
+   use_large_reloc = 0;
 #endif
 
/* Collect up the relocations */
@@ -1114,8 +1145,13 @@ static void emit_relocs(int as_text, int use_real_mode)
 * gas will like.
 */
printf(".section \".data.reloc\",\"a\"\n");
-   printf(".balign 4\n");
-   write_reloc = write32_as_text;
+   if (use_large_reloc) {
+   printf(".balign 8\n");
+   write_reloc = write64_as_text;
+   } else {
+   printf(".balign 4\n");
+   write_reloc = write32_as_text;
+   }
}
 
if (use_real_mode) {
@@ -1183,7 +1219,7 @@ static void print_reloc_info(void)
 
 void process(FILE *fp, int use_real_mode, int as_text,
 int show_absolute_syms, int show_absolute_relocs,
-int show_reloc_info)
+int show_reloc_info, int use_large_reloc)
 {
regex_init(use_real_mode);
read_ehdr(fp);
@@ -1206,5 +1242,5 @@ void process(FILE *fp, int use_real_mode, int as_text,
print_reloc_info();
return;
}
-   emit_relocs(as_text, use_real_mode);
+   emit_relocs(as_text, use_real_mode, use_large_reloc);
 }
diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h
index 43c83c0fd22c..3d401da59df7 100644
--- a/arch/x86/tools/relocs.h
+++ b/arch/x86/tools/relocs.h
@@ -31,8 +31,8 @@ enum symtype {
 
 void process_32(FILE *fp, int use_real_mode, int as_text,
int show_absolute_syms, int show_absolute_relocs,
-   int show_reloc_info);
+   int show_reloc_info, int use_large_reloc);
 

[Xen-devel] [PATCH v3 17/27] x86/relocs: Handle PIE relocations

[Thomas Garnier]

Change the relocation tool to correctly handle relocations generated by
-fPIE option:

 - Add relocation for each entry of the .got section given the linker does not
   generate R_X86_64_GLOB_DAT on a simple link.
 - Ignore R_X86_64_GOTPCREL.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c | 93 -
 1 file changed, 92 insertions(+), 1 deletion(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 220e97841e49..a35cc337f883 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -32,6 +32,7 @@ struct section {
Elf_Sym*symtab;
Elf_Rel*reltab;
char   *strtab;
+   Elf_Addr   *got;
 };
 static struct section *secs;
 
@@ -293,6 +294,35 @@ static Elf_Sym *sym_lookup(const char *symname)
return 0;
 }
 
+static Elf_Sym *sym_lookup_addr(Elf_Addr addr, const char **name)
+{
+   int i;
+   for (i = 0; i < ehdr.e_shnum; i++) {
+   struct section *sec = [i];
+   long nsyms;
+   Elf_Sym *symtab;
+   Elf_Sym *sym;
+
+   if (sec->shdr.sh_type != SHT_SYMTAB)
+   continue;
+
+   nsyms = sec->shdr.sh_size/sizeof(Elf_Sym);
+   symtab = sec->symtab;
+
+   for (sym = symtab; --nsyms >= 0; sym++) {
+   if (sym->st_value == addr) {
+   if (name) {
+   *name = sym_name(sec->link->strtab,
+sym);
+   }
+   return sym;
+   }
+   }
+   }
+   return 0;
+}
+
+
 #if BYTE_ORDER == LITTLE_ENDIAN
 #define le16_to_cpu(val) (val)
 #define le32_to_cpu(val) (val)
@@ -513,6 +543,33 @@ static void read_relocs(FILE *fp)
}
 }
 
+static void read_got(FILE *fp)
+{
+   int i;
+   for (i = 0; i < ehdr.e_shnum; i++) {
+   struct section *sec = [i];
+   sec->got = NULL;
+   if (sec->shdr.sh_type != SHT_PROGBITS ||
+   strcmp(sec_name(i), ".got")) {
+   continue;
+   }
+   sec->got = malloc(sec->shdr.sh_size);
+   if (!sec->got) {
+   die("malloc of %d bytes for got failed\n",
+   sec->shdr.sh_size);
+   }
+   if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
+   die("Seek to %d failed: %s\n",
+   sec->shdr.sh_offset, strerror(errno));
+   }
+   if (fread(sec->got, 1, sec->shdr.sh_size, fp)
+   != sec->shdr.sh_size) {
+   die("Cannot read got: %s\n",
+   strerror(errno));
+   }
+   }
+}
+
 
 static void print_absolute_symbols(void)
 {
@@ -643,6 +700,32 @@ static void add_reloc(struct relocs *r, uint32_t offset)
r->offset[r->count++] = offset;
 }
 
+/*
+ * The linker does not generate relocations for the GOT for the kernel.
+ * If a GOT is found, simulate the relocations that should have been included.
+ */
+static void walk_got_table(int (*process)(struct section *sec, Elf_Rel *rel,
+ Elf_Sym *sym, const char *symname),
+  struct section *sec)
+{
+   int i;
+   Elf_Addr entry;
+   Elf_Sym *sym;
+   const char *symname;
+   Elf_Rel rel;
+
+   for (i = 0; i < sec->shdr.sh_size/sizeof(Elf_Addr); i++) {
+   entry = sec->got[i];
+   sym = sym_lookup_addr(entry, );
+   if (!sym)
+   die("Could not found got symbol for entry %d\n", i);
+   rel.r_offset = sec->shdr.sh_addr + i * sizeof(Elf_Addr);
+   rel.r_info = ELF_BITS == 64 ? R_X86_64_GLOB_DAT
+: R_386_GLOB_DAT;
+   process(sec, , sym, symname);
+   }
+}
+
 static void walk_relocs(int (*process)(struct section *sec, Elf_Rel *rel,
Elf_Sym *sym, const char *symname))
 {
@@ -656,6 +739,8 @@ static void walk_relocs(int (*process)(struct section *sec, 
Elf_Rel *rel,
struct section *sec = [i];
 
if (sec->shdr.sh_type != SHT_REL_TYPE) {
+   if (sec->got)
+   walk_got_table(process, sec);
continue;
}
sec_symtab  = sec->link;
@@ -765,6 +850,7 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
offset += per_cpu_load_addr;
 
switch (r_type) {
+   case R_X86_64_GOTPCREL:
case R_X86_64_NONE:
/* NONE can be ignored. */
break;
@@ -809,7 +895,7 @@ static int do_reloc64(struct section *sec, Elf_Rel 

[Xen-devel] [PATCH v3 25/27] x86/pie: Add option to build the kernel as PIE

[Thomas Garnier]

Add the CONFIG_X86_PIE option which builds the kernel as a Position
Independent Executable (PIE). The kernel is currently build with the
mcmodel=kernel option which forces it to stay on the top 2G of the
virtual address space. With PIE, the kernel will be able to move below
the current limit.

The --emit-relocs linker option was kept instead of using -pie to limit
the impact on mapped sections. Any incompatible relocation will be
catch by the arch/x86/tools/relocs binary at compile time.

If segment based stack cookies are enabled, try to use the compiler
option to select the segment register. If not available, automatically
enabled global stack cookie in auto mode. Otherwise, recommend
compiler update or global stack cookie option.

Performance/Size impact:

Size of vmlinux (Default configuration):
 File size:
 - PIE disabled: +0.18%
 - PIE enabled: -1.977% (less relocations)
 .text section:
 - PIE disabled: same
 - PIE enabled: same

Size of vmlinux (Ubuntu configuration):
 File size:
 - PIE disabled: +0.21%
 - PIE enabled: +10%
 .text section:
 - PIE disabled: same
 - PIE enabled: +0.001%

The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.

Hackbench (50% and 1600% on thread/process for pipe/sockets):
 - PIE disabled: no significant change (avg -/+ 0.5% on latest test).
 - PIE enabled: between -1% to +1% in average (default and Ubuntu config).

Kernbench (average of 10 Half and Optimal runs):
 Elapsed Time:
 - PIE disabled: no significant change (avg -0.5%)
 - PIE enabled: average -0.5% to +0.5%
 System Time:
 - PIE disabled: no significant change (avg -0.1%)
 - PIE enabled: average -0.4% to +0.4%.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303

Signed-off-by: Thomas Garnier 

merge pie
---
 arch/x86/Kconfig  |  8 
 arch/x86/Makefile | 45 -
 2 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 28eb2b3757bf..26d5d4942777 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2215,6 +2215,14 @@ config X86_GLOBAL_STACKPROTECTOR
 
   If unsure, say N
 
+config X86_PIE
+   bool
+   depends on X86_64
+   select DEFAULT_HIDDEN
+   select WEAK_PROVIDE_HIDDEN
+   select DYNAMIC_MODULE_BASE
+   select MODULE_REL_CRCS if MODVERSIONS
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 20bb6cbd8938..c92bcca4400c 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -60,6 +60,8 @@ endif
 KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
 KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
 
+stackglobal := $(call cc-option-yn, -mstack-protector-guard=global)
+
 ifeq ($(CONFIG_X86_32),y)
 BITS := 32
 UTS_MACHINE := i386
@@ -135,7 +137,48 @@ else
 
 KBUILD_CFLAGS += -mno-red-zone
 ifdef CONFIG_X86_PIE
+KBUILD_CFLAGS += -fPIE
 KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
+
+# Relax relocation in both CFLAGS and LDFLAGS to support older 
compilers
+KBUILD_CFLAGS += $(call cc-option,-Wa$(comma)-mrelax-relocations=no)
+LDFLAGS_vmlinux += $(call ld-option,--no-relax)
+KBUILD_LDFLAGS_MODULE += $(call ld-option,--no-relax)
+
+# Stack validation is not yet support due to self-referenced switches
+ifdef CONFIG_STACK_VALIDATION
+$(warning CONFIG_STACK_VALIDATION is not yet supported for x86_64 pie \
+   build.)
+SKIP_STACK_VALIDATION := 1
+export SKIP_STACK_VALIDATION
+endif
+
+ifndef CONFIG_CC_STACKPROTECTOR_NONE
+ifndef CONFIG_X86_GLOBAL_STACKPROTECTOR
+stackseg-flag := -mstack-protector-guard-reg=%gs
+ifeq ($(call cc-option-yn,$(stackseg-flag)),n)
+# Try to enable global stack cookie if possible
+ifeq ($(stackglobal), y)
+$(warning Cannot use CONFIG_CC_STACKPROTECTOR_* while \
+building a position independent kernel. \
+Default to global stack protector \
+(CONFIG_X86_GLOBAL_STACKPROTECTOR).)
+CONFIG_X86_GLOBAL_STACKPROTECTOR := y
+KBUILD_CFLAGS += -DCONFIG_X86_GLOBAL_STACKPROTECTOR
+KBUILD_AFLAGS += -DCONFIG_X86_GLOBAL_STACKPROTECTOR
+else
+$(error echo Cannot use \
+CONFIG_CC_STACKPROTECTOR_(REGULAR|STRONG|AUTO) 
\
+while building a position independent binary. \
+Update your compiler or use \
+

[Xen-devel] [PATCH v3 15/27] compiler: Option to default to hidden symbols

[Thomas Garnier]

Provide an option to default visibility to hidden except for key
symbols. This option is disabled by default and will be used by x86_64
PIE support to remove errors between compilation units.

The default visibility is also enabled for external symbols that are
compared as they maybe equals (start/end of sections). In this case,
older versions of GCC will remove the comparison if the symbols are
hidden. This issue exists at least on gcc 4.9 and before.

Signed-off-by: Thomas Garnier 
---
 arch/x86/boot/boot.h |  2 +-
 arch/x86/include/asm/setup.h |  2 +-
 arch/x86/kernel/cpu/microcode/core.c |  4 ++--
 drivers/base/firmware_loader/main.c  |  4 ++--
 include/asm-generic/sections.h   |  6 ++
 include/linux/compiler.h |  7 +++
 init/Kconfig |  7 +++
 kernel/kallsyms.c| 16 
 kernel/trace/trace.h |  4 ++--
 lib/dynamic_debug.c  |  4 ++--
 10 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index ef5a9cc66fb8..d726c35bdd96 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -193,7 +193,7 @@ static inline bool memcmp_gs(const void *s1, addr_t s2, 
size_t len)
 }
 
 /* Heap -- available for dynamic lists. */
-extern char _end[];
+extern char _end[] __default_visibility;
 extern char *HEAP;
 extern char *heap_end;
 #define RESET_HEAP() ((void *)( HEAP = _end ))
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ae13bc974416..083a6e99b884 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -68,7 +68,7 @@ static inline void x86_ce4100_early_setup(void) { }
  * This is set up by the setup-routine at boot-time
  */
 extern struct boot_params boot_params;
-extern char _text[];
+extern char _text[] __default_visibility;
 
 static inline bool kaslr_enabled(void)
 {
diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index 77e201301528..6a4f5d9d7eb6 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -149,8 +149,8 @@ static bool __init check_loader_disabled_bsp(void)
return *res;
 }
 
-extern struct builtin_fw __start_builtin_fw[];
-extern struct builtin_fw __end_builtin_fw[];
+extern struct builtin_fw __start_builtin_fw[] __default_visibility;
+extern struct builtin_fw __end_builtin_fw[] __default_visibility;
 
 bool get_builtin_firmware(struct cpio_data *cd, const char *name)
 {
diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 0943e7065e0e..2ffd019af2d4 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -94,8 +94,8 @@ static struct firmware_cache fw_cache;
 
 #ifdef CONFIG_FW_LOADER
 
-extern struct builtin_fw __start_builtin_fw[];
-extern struct builtin_fw __end_builtin_fw[];
+extern struct builtin_fw __start_builtin_fw[] __default_visibility;
+extern struct builtin_fw __end_builtin_fw[] __default_visibility;
 
 static void fw_copy_to_prealloc_buf(struct firmware *fw,
void *buf, size_t size)
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 849cd8eb5ca0..0a0e23405ddd 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -32,6 +32,9 @@
  * __softirqentry_text_start, __softirqentry_text_end
  * __start_opd, __end_opd
  */
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility push(default)
+#endif
 extern char _text[], _stext[], _etext[];
 extern char _data[], _sdata[], _edata[];
 extern char __bss_start[], __bss_stop[];
@@ -49,6 +52,9 @@ extern char __start_once[], __end_once[];
 
 /* Start and end of .ctors section - used for constructor calls. */
 extern char __ctors_start[], __ctors_end[];
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility pop
+#endif
 
 /* Start and end of .opd section - used for function descriptors. */
 extern char __start_opd[], __end_opd[];
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 341b6cf8c029..81a9986cad78 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -278,6 +278,13 @@ unsigned long read_word_at_a_time(const void *addr)
__u.__val;  \
 })
 
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility push(hidden)
+#define __default_visibility  __attribute__((visibility ("default")))
+#else
+#define __default_visibility
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASSEMBLY__ */
diff --git a/init/Kconfig b/init/Kconfig
index 8915a3ce5f0c..0fc3a58d9f2f 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1694,6 +1694,13 @@ config PROFILING
 config TRACEPOINTS
bool
 
+#
+# Default to hidden visibility for all symbols.
+# Useful for Position Independent Code to reduce global references.
+#
+config DEFAULT_HIDDEN
+   bool
+
 

[Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

[Thomas Garnier]

When using -fPIE/PIC with function tracing, the compiler generates a
call through the GOT (call *__fentry__@GOTPCREL). This instruction
takes 6 bytes instead of 5 on the usual relative call.

If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
so ftrace can handle the previous 5-bytes as before.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/ftrace.h   |  6 +++--
 arch/x86/include/asm/sections.h |  4 
 arch/x86/kernel/ftrace.c| 42 +++--
 3 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index c18ed65287d5..8f2decce38d8 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -25,9 +25,11 @@ extern void __fentry__(void);
 static inline unsigned long ftrace_call_adjust(unsigned long addr)
 {
/*
-* addr is the address of the mcount call instruction.
-* recordmcount does the necessary offset calculation.
+* addr is the address of the mcount call instruction. PIE has always a
+* byte added to the start of the function.
 */
+   if (IS_ENABLED(CONFIG_X86_PIE))
+   addr -= 1;
return addr;
 }
 
diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index 5c019d23d06b..da3d98bb2bcb 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -13,4 +13,8 @@ extern char __end_rodata_hpage_align[];
 extern char __entry_trampoline_start[], __entry_trampoline_end[];
 #endif
 
+#if defined(CONFIG_X86_PIE)
+extern char __start_got[], __end_got[];
+#endif
+
 #endif /* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 01ebcb6f263e..73b3c30cb7a3 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -102,7 +102,7 @@ static const unsigned char *ftrace_nop_replace(void)
 
 static int
 ftrace_modify_code_direct(unsigned long ip, unsigned const char *old_code,
-  unsigned const char *new_code)
+ unsigned const char *new_code)
 {
unsigned char replaced[MCOUNT_INSN_SIZE];
 
@@ -135,6 +135,44 @@ ftrace_modify_code_direct(unsigned long ip, unsigned const 
char *old_code,
return 0;
 }
 
+/* Bytes before call GOT offset */
+const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
+
+static int
+ftrace_modify_initial_code(unsigned long ip, unsigned const char *old_code,
+  unsigned const char *new_code)
+{
+   unsigned char replaced[MCOUNT_INSN_SIZE + 1];
+
+   ftrace_expected = old_code;
+
+   /*
+* If PIE is not enabled or no GOT call was found, default to the
+* original approach to code modification.
+*/
+   if (!IS_ENABLED(CONFIG_X86_PIE) ||
+   probe_kernel_read(replaced, (void *)ip, sizeof(replaced)) ||
+   memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
+   return ftrace_modify_code_direct(ip, old_code, new_code);
+
+   /*
+* Build a nop slide with a 5-byte nop and 1-byte nop to keep the ftrace
+* hooking algorithm working with the expected 5 bytes instruction.
+*/
+   memcpy(replaced, new_code, MCOUNT_INSN_SIZE);
+   replaced[MCOUNT_INSN_SIZE] = ideal_nops[1][0];
+
+   ip = text_ip_addr(ip);
+
+   if (probe_kernel_write((void *)ip, replaced, sizeof(replaced)))
+   return -EPERM;
+
+   sync_core();
+
+   return 0;
+
+}
+
 int ftrace_make_nop(struct module *mod,
struct dyn_ftrace *rec, unsigned long addr)
 {
@@ -153,7 +191,7 @@ int ftrace_make_nop(struct module *mod,
 * just modify the code directly.
 */
if (addr == MCOUNT_ADDR)
-   return ftrace_modify_code_direct(rec->ip, old, new);
+   return ftrace_modify_initial_code(rec->ip, old, new);
 
ftrace_expected = NULL;
 
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 18/27] xen: Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use the new _ASM_MOVABS macro which get a
symbol reference while being PIE compatible. Adapt the relocation tool
to ignore 32-bit Xen code.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c | 16 +++-
 arch/x86/xen/xen-head.S | 11 ++-
 arch/x86/xen/xen-pvh.S  | 13 +
 3 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index a35cc337f883..29283ad3950f 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -832,6 +832,16 @@ static int is_percpu_sym(ElfW(Sym) *sym, const char 
*symname)
strncmp(symname, "init_per_cpu_", 13);
 }
 
+/*
+ * Check if the 32-bit relocation is within the xenpvh 32-bit code.
+ * If so, ignores it.
+ */
+static int is_in_xenpvh_assembly(ElfW(Addr) offset)
+{
+   ElfW(Sym) *sym = sym_lookup("pvh_start_xen");
+   return sym && (offset >= sym->st_value) &&
+   (offset < (sym->st_value + sym->st_size));
+}
 
 static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
  const char *symname)
@@ -895,8 +905,12 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
 * the relocations are processed.
 * Make sure that the offset will fit.
 */
-   if (r_type != R_X86_64_64 && (int32_t)offset != (int64_t)offset)
+   if (r_type != R_X86_64_64 &&
+   (int32_t)offset != (int64_t)offset) {
+   if (is_in_xenpvh_assembly(offset))
+   break;
die("Relocation offset doesn't fit in 32 bits\n");
+   }
 
if (r_type == R_X86_64_64)
add_reloc(, offset);
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 5077ead5e59c..4418ff0a1d96 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -28,14 +28,15 @@ ENTRY(startup_xen)
 
/* Clear .bss */
xor %eax,%eax
-   mov $__bss_start, %_ASM_DI
-   mov $__bss_stop, %_ASM_CX
+   _ASM_MOVABS $__bss_start, %_ASM_DI
+   _ASM_MOVABS $__bss_stop, %_ASM_CX
sub %_ASM_DI, %_ASM_CX
shr $__ASM_SEL(2, 3), %_ASM_CX
rep __ASM_SIZE(stos)
 
-   mov %_ASM_SI, xen_start_info
-   mov $init_thread_union+THREAD_SIZE, %_ASM_SP
+   _ASM_MOVABS $xen_start_info, %_ASM_AX
+   _ASM_MOV %_ASM_SI, (%_ASM_AX)
+   _ASM_MOVABS $init_thread_union+THREAD_SIZE, %_ASM_SP
 
 #ifdef CONFIG_X86_64
/* Set up %gs.
@@ -46,7 +47,7 @@ ENTRY(startup_xen)
 * init data section till per cpu areas are set up.
 */
movl$MSR_GS_BASE,%ecx
-   movq$INIT_PER_CPU_VAR(irq_stack_union),%rax
+   movabsq $INIT_PER_CPU_VAR(irq_stack_union),%rax
cdq
wrmsr
 #endif
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index e1a5fbeae08d..43e234c7c2de 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -101,8 +101,8 @@ ENTRY(pvh_start_xen)
call xen_prepare_pvh
 
/* startup_64 expects boot_params in %rsi. */
-   mov $_pa(pvh_bootparams), %rsi
-   mov $_pa(startup_64), %rax
+   movabs $_pa(pvh_bootparams), %rsi
+   movabs $_pa(startup_64), %rax
jmp *%rax
 
 #else /* CONFIG_X86_64 */
@@ -137,10 +137,15 @@ END(pvh_start_xen)
 
.section ".init.data","aw"
.balign 8
+   /*
+* Use a quad for _pa(gdt_start) because PIE does not understand a
+* long is enough. The resulting value will still be in the lower long
+* part.
+*/
 gdt:
.word gdt_end - gdt_start
-   .long _pa(gdt_start)
-   .word 0
+   .quad _pa(gdt_start)
+   .balign 8
 gdt_start:
.quad 0x/* NULL descriptor */
.quad 0x/* reserved */
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 23/27] x86/modules: Adapt module loading for PIE support

[Thomas Garnier]

Adapt module loading to support PIE relocations. Generate dynamic GOT if
a symbol requires it but no entry exist in the kernel GOT.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Makefile   |   4 +
 arch/x86/include/asm/module.h   |  11 ++
 arch/x86/include/asm/sections.h |   4 +
 arch/x86/kernel/module.c| 181 +++-
 arch/x86/kernel/module.lds  |   3 +
 5 files changed, 198 insertions(+), 5 deletions(-)
 create mode 100644 arch/x86/kernel/module.lds

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 277ffc57ae13..20bb6cbd8938 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -134,7 +134,11 @@ else
 KBUILD_CFLAGS += $(cflags-y)
 
 KBUILD_CFLAGS += -mno-red-zone
+ifdef CONFIG_X86_PIE
+KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
+else
 KBUILD_CFLAGS += -mcmodel=kernel
+endif
 
 # -funit-at-a-time shrinks the kernel .text considerably
 # unfortunately it makes reading oopses harder.
diff --git a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
index 7948a17febb4..68ff05e14288 100644
--- a/arch/x86/include/asm/module.h
+++ b/arch/x86/include/asm/module.h
@@ -5,12 +5,23 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86_PIE
+struct mod_got_sec {
+   struct elf64_shdr   *got;
+   int got_num_entries;
+   int got_max_entries;
+};
+#endif
+
 struct mod_arch_specific {
 #ifdef CONFIG_UNWINDER_ORC
unsigned int num_orcs;
int *orc_unwind_ip;
struct orc_entry *orc_unwind;
 #endif
+#ifdef CONFIG_X86_PIE
+   struct mod_got_sec  core;
+#endif
 };
 
 #ifdef CONFIG_X86_64
diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index da3d98bb2bcb..89b3a95c8d11 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -17,4 +17,8 @@ extern char __entry_trampoline_start[], 
__entry_trampoline_end[];
 extern char __start_got[], __end_got[];
 #endif
 
+#if defined(CONFIG_X86_PIE)
+extern char __start_got[], __end_got[];
+#endif
+
 #endif /* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index f58336af095c..88895f3d474b 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -77,6 +78,173 @@ static unsigned long int get_module_load_offset(void)
 }
 #endif
 
+#ifdef CONFIG_X86_PIE
+static u64 find_got_kernel_entry(Elf64_Sym *sym, const Elf64_Rela *rela)
+{
+   u64 *pos;
+
+   for (pos = (u64*)__start_got; pos < (u64*)__end_got; pos++) {
+   if (*pos == sym->st_value)
+   return (u64)pos + rela->r_addend;
+   }
+
+   return 0;
+}
+
+static u64 module_emit_got_entry(struct module *mod, void *loc,
+const Elf64_Rela *rela, Elf64_Sym *sym)
+{
+   struct mod_got_sec *gotsec = >arch.core;
+   u64 *got = (u64*)gotsec->got->sh_addr;
+   int i = gotsec->got_num_entries;
+   u64 ret;
+
+   /* Check if we can use the kernel GOT */
+   ret = find_got_kernel_entry(sym, rela);
+   if (ret)
+   return ret;
+
+   got[i] = sym->st_value;
+
+   /*
+* Check if the entry we just created is a duplicate. Given that the
+* relocations are sorted, this will be the last entry we allocated.
+* (if one exists).
+*/
+   if (i > 0 && got[i] == got[i - 2]) {
+   ret = (u64)[i - 1];
+   } else {
+   gotsec->got_num_entries++;
+   BUG_ON(gotsec->got_num_entries > gotsec->got_max_entries);
+   ret = (u64)[i];
+   }
+
+   return ret + rela->r_addend;
+}
+
+#define cmp_3way(a,b)  ((a) < (b) ? -1 : (a) > (b))
+
+static int cmp_rela(const void *a, const void *b)
+{
+   const Elf64_Rela *x = a, *y = b;
+   int i;
+
+   /* sort by type, symbol index and addend */
+   i = cmp_3way(ELF64_R_TYPE(x->r_info), ELF64_R_TYPE(y->r_info));
+   if (i == 0)
+   i = cmp_3way(ELF64_R_SYM(x->r_info), ELF64_R_SYM(y->r_info));
+   if (i == 0)
+   i = cmp_3way(x->r_addend, y->r_addend);
+   return i;
+}
+
+static bool duplicate_rel(const Elf64_Rela *rela, int num)
+{
+   /*
+* Entries are sorted by type, symbol index and addend. That means
+* that, if a duplicate entry exists, it must be in the preceding
+* slot.
+*/
+   return num > 0 && cmp_rela(rela + num, rela + num - 1) == 0;
+}
+
+static unsigned int count_gots(Elf64_Sym *syms, Elf64_Rela *rela, int num)
+{
+   unsigned int ret = 0;
+   Elf64_Sym *s;
+   int i;
+
+   for (i = 0; i < num; i++) {
+   switch 

[Xen-devel] [PATCH v3 27/27] x86/kaslr: Add option to extend KASLR range from 1GB to 3GB

[Thomas Garnier]

Add a new CONFIG_RANDOMIZE_BASE_LARGE option to benefit from PIE
support. It increases the KASLR range from 1GB to 3GB. The new range
stars at 0x just above the EFI memory region. This
option is off by default.

The boot code is adapted to create the appropriate page table spanning
three PUD pages.

The relocation table uses 64-bit integers generated with the updated
relocation tool with the large-reloc option.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig | 21 +
 arch/x86/boot/compressed/Makefile|  5 +
 arch/x86/boot/compressed/misc.c  | 10 +-
 arch/x86/include/asm/page_64_types.h |  9 +
 arch/x86/kernel/head64.c | 15 ---
 arch/x86/kernel/head_64.S| 11 ++-
 6 files changed, 66 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 26d5d4942777..3596a7a76ff0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2223,6 +2223,27 @@ config X86_PIE
select DYNAMIC_MODULE_BASE
select MODULE_REL_CRCS if MODVERSIONS
 
+config RANDOMIZE_BASE_LARGE
+   bool "Increase the randomization range of the kernel image"
+   depends on X86_64 && RANDOMIZE_BASE
+   select X86_PIE
+   select X86_MODULE_PLTS if MODULES
+   default n
+   ---help---
+ Build the kernel as a Position Independent Executable (PIE) and
+ increase the available randomization range from 1GB to 3GB.
+
+ This option impacts performance on kernel CPU intensive workloads up
+ to 10% due to PIE generated code. Impact on user-mode processes and
+ typical usage would be significantly less (0.50% when you build the
+ kernel).
+
+ The kernel and modules will generate slightly more assembly (1 to 2%
+ increase on the .text sections). The vmlinux binary will be
+ significantly smaller due to less relocations.
+
+ If unsure say N
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index fa42f895fdde..8497ebd5e078 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -116,7 +116,12 @@ $(obj)/vmlinux.bin: vmlinux FORCE
 
 targets += $(patsubst $(obj)/%,%,$(vmlinux-objs-y)) vmlinux.bin.all 
vmlinux.relocs
 
+# Large randomization require bigger relocation table
+ifeq ($(CONFIG_RANDOMIZE_BASE_LARGE),y)
+CMD_RELOCS = arch/x86/tools/relocs --large-reloc
+else
 CMD_RELOCS = arch/x86/tools/relocs
+endif
 quiet_cmd_relocs = RELOCS  $@
   cmd_relocs = $(CMD_RELOCS) $< > $@;$(CMD_RELOCS) --abs-relocs $<
 $(obj)/vmlinux.relocs: vmlinux FORCE
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 8dd1d5ccae58..28d17bd5bad8 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -171,10 +171,18 @@ void __puthex(unsigned long value)
 }
 
 #if CONFIG_X86_NEED_RELOCS
+
+/* Large randomization go lower than -2G and use large relocation table */
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+typedef long rel_t;
+#else
+typedef int rel_t;
+#endif
+
 static void handle_relocations(void *output, unsigned long output_len,
   unsigned long virt_addr)
 {
-   int *reloc;
+   rel_t *reloc;
unsigned long delta, map, ptr;
unsigned long min_addr = (unsigned long)output;
unsigned long max_addr = min_addr + (VO___bss_start - VO__text);
diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 2c5a966dc222..85ea681421d2 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -46,7 +46,11 @@
 #define __PAGE_OFFSET   __PAGE_OFFSET_BASE_L4
 #endif /* CONFIG_DYNAMIC_MEMORY_LAYOUT */
 
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define __START_KERNEL_map _AC(0x, UL)
+#else
 #define __START_KERNEL_map _AC(0x8000, UL)
+#endif /* CONFIG_RANDOMIZE_BASE_LARGE */
 
 /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
 
@@ -64,9 +68,14 @@
  * 512MiB by default, leaving 1.5GiB for modules once the page tables
  * are fully set up. If kernel ASLR is configured, it can extend the
  * kernel page table mapping, reducing the size of the modules area.
+ * On PIE, we relocate the binary 2G lower so add this extra space.
  */
 #if defined(CONFIG_RANDOMIZE_BASE)
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define KERNEL_IMAGE_SIZE  (_AC(3, UL) * 1024 * 1024 * 1024)
+#else
 #define KERNEL_IMAGE_SIZE  (1024 * 1024 * 1024)
+#endif
 #else
 #define KERNEL_IMAGE_SIZE  (512 * 1024 * 1024)
 #endif
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 3a1ce822e1c0..e18cc23b9d99 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -63,6 +63,7 @@ EXPORT_SYMBOL(vmemmap_base);
 

[Xen-devel] [PATCH v3 20/27] x86: Support global stack cookie

[Thomas Garnier]

Add an off-by-default configuration option to use a global stack cookie
instead of the default TLS. This configuration option will only be used
with PIE binaries.

For kernel stack cookie, the compiler uses the mcmodel=kernel to switch
between the fs segment to gs segment. A PIE binary does not use
mcmodel=kernel because it can be relocated anywhere, therefore the
compiler will default to the fs segment register. This is fixed on the
latest version of gcc.

If the segment selector is available, it will be automatically added. If
the automatic configuration was selected, a warning is written and the
global variable stack cookie is used. If a specific stack mode was
selected (regular or strong) and the compiler does not support selecting
the segment register, an error is emitted.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig  | 12 
 arch/x86/Makefile |  9 +
 arch/x86/entry/entry_32.S |  3 ++-
 arch/x86/entry/entry_64.S |  3 ++-
 arch/x86/include/asm/processor.h  |  3 ++-
 arch/x86/include/asm/stackprotector.h | 19 ++-
 arch/x86/kernel/asm-offsets.c |  3 ++-
 arch/x86/kernel/asm-offsets_32.c  |  3 ++-
 arch/x86/kernel/asm-offsets_64.c  |  3 ++-
 arch/x86/kernel/cpu/common.c  |  3 ++-
 arch/x86/kernel/head_32.S |  3 ++-
 arch/x86/kernel/process.c |  5 +
 12 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dda87a331a7e..0fc2e981458d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2199,6 +2199,18 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
 
   If unsure, leave at the default value.
 
+config X86_GLOBAL_STACKPROTECTOR
+   bool "Stack cookie using a global variable"
+   depends on CC_STACKPROTECTOR_AUTO
+   default n
+   ---help---
+  This option turns on the "stack-protector" GCC feature using a global
+  variable instead of a segment register. It is useful when the
+  compiler does not support custom segment registers when building a
+  position independent (PIE) binary.
+
+  If unsure, say N
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 60135cbd905c..277ffc57ae13 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -141,6 +141,15 @@ else
 KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
 endif
 
+ifdef CONFIG_X86_GLOBAL_STACKPROTECTOR
+ifeq ($(call cc-option, -mstack-protector-guard=global),)
+$(error Cannot use CONFIG_X86_GLOBAL_STACKPROTECTOR: \
+-mstack-protector-guard=global not supported \
+by compiler)
+endif
+KBUILD_CFLAGS += -mstack-protector-guard=global
+endif
+
 ifdef CONFIG_X86_X32
x32_ld_ok := $(call try-run,\
/bin/echo -e '1: .quad 1b' | \
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index bb4f540be234..2f9bdbc6be6d 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -241,7 +241,8 @@ ENTRY(__switch_to_asm)
movl%esp, TASK_threadsp(%eax)
movlTASK_threadsp(%edx), %esp
 
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
movlTASK_stack_canary(%edx), %ebx
movl%ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset
 #endif
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index c1700b00b1b6..c8b4e8a7d1e1 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -359,7 +359,8 @@ ENTRY(__switch_to_asm)
movq%rsp, TASK_threadsp(%rdi)
movqTASK_threadsp(%rsi), %rsp
 
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
movqTASK_stack_canary(%rsi), %rbx
movq%rbx, PER_CPU_VAR(irq_stack_union + stack_canary_offset)
 #endif
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 5cf36fa30254..6e5d9ac3bf17 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -414,7 +414,8 @@ extern asmlinkage void ignore_sysret(void);
 void save_fsgs_for_kvm(void);
 #endif
 #else  /* X86_64 */
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
 /*
  * Make sure stack canary segment base is cached-aligned:
  *   "For Intel Atom processors, avoid non zero segment base address
diff --git a/arch/x86/include/asm/stackprotector.h 
b/arch/x86/include/asm/stackprotector.h
index 371b3a4af000..5063f57d99f5 100644
--- a/arch/x86/include/asm/stackprotector.h
+++ b/arch/x86/include/asm/stackprotector.h
@@ -52,6 +52,10 @@
 #define 

[Xen-devel] [PATCH v3 01/27] x86/crypto: Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/crypto/aes-x86_64-asm_64.S  | 45 +
 arch/x86/crypto/aesni-intel_asm.S|  8 +-
 arch/x86/crypto/aesni-intel_avx-x86_64.S |  6 +-
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  | 42 -
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 -
 arch/x86/crypto/camellia-x86_64-asm_64.S |  8 +-
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S| 50 +-
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S| 44 +
 arch/x86/crypto/des3_ede-asm_64.S| 96 +---
 arch/x86/crypto/ghash-clmulni-intel_asm.S|  4 +-
 arch/x86/crypto/glue_helper-asm-avx.S|  4 +-
 arch/x86/crypto/glue_helper-asm-avx2.S   |  6 +-
 arch/x86/crypto/sha256-avx2-asm.S| 23 +++--
 13 files changed, 221 insertions(+), 159 deletions(-)

diff --git a/arch/x86/crypto/aes-x86_64-asm_64.S 
b/arch/x86/crypto/aes-x86_64-asm_64.S
index 8739cf7795de..86fa068e5e81 100644
--- a/arch/x86/crypto/aes-x86_64-asm_64.S
+++ b/arch/x86/crypto/aes-x86_64-asm_64.S
@@ -48,8 +48,12 @@
 #define R10%r10
 #define R11%r11
 
+/* Hold global for PIE suport */
+#define RBASE  %r12
+
 #define prologue(FUNC,KEY,B128,B192,r1,r2,r5,r6,r7,r8,r9,r10,r11) \
ENTRY(FUNC);\
+   pushq   RBASE;  \
movqr1,r2;  \
leaqKEY+48(r8),r9;  \
movqr10,r11;\
@@ -74,54 +78,63 @@
movlr6 ## E,4(r9);  \
movlr7 ## E,8(r9);  \
movlr8 ## E,12(r9); \
+   popqRBASE;  \
ret;\
ENDPROC(FUNC);
 
+#define round_mov(tab_off, reg_i, reg_o) \
+   leaqtab_off(%rip), RBASE; \
+   movl(RBASE,reg_i,4), reg_o;
+
+#define round_xor(tab_off, reg_i, reg_o) \
+   leaqtab_off(%rip), RBASE; \
+   xorl(RBASE,reg_i,4), reg_o;
+
 #define round(TAB,OFFSET,r1,r2,r3,r4,r5,r6,r7,r8,ra,rb,rc,rd) \
movzbl  r2 ## H,r5 ## E;\
movzbl  r2 ## L,r6 ## E;\
-   movlTAB+1024(,r5,4),r5 ## E;\
+   round_mov(TAB+1024, r5, r5 ## E)\
movwr4 ## X,r2 ## X;\
-   movlTAB(,r6,4),r6 ## E; \
+   round_mov(TAB, r6, r6 ## E) \
roll$16,r2 ## E;\
shrl$16,r4 ## E;\
movzbl  r4 ## L,r7 ## E;\
movzbl  r4 ## H,r4 ## E;\
xorlOFFSET(r8),ra ## E; \
xorlOFFSET+4(r8),rb ## E;   \
-   xorlTAB+3072(,r4,4),r5 ## E;\
-   xorlTAB+2048(,r7,4),r6 ## E;\
+   round_xor(TAB+3072, r4, r5 ## E)\
+   round_xor(TAB+2048, r7, r6 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r4 ## E;\
-   movlTAB+1024(,r4,4),r4 ## E;\
+   round_mov(TAB+1024, r4, r4 ## E)\
movwr3 ## X,r1 ## X;\
roll$16,r1 ## E;\
shrl$16,r3 ## E;\
-   xorlTAB(,r7,4),r5 ## E; \
+   round_xor(TAB, r7, r5 ## E) \
movzbl  r3 ## L,r7 ## E;\
movzbl  r3 ## H,r3 ## E;\
-   xorlTAB+3072(,r3,4),r4 ## E;\
-   xorlTAB+2048(,r7,4),r5 ## E;\
+   round_xor(TAB+3072, r3, r4 ## E)\
+   round_xor(TAB+2048, r7, r5 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r3 ## E;\
shrl$16,r1 ## E;\
-   xorlTAB+3072(,r3,4),r6 ## E;\
-   movlTAB+2048(,r7,4),r3 ## E;\
+   round_xor(TAB+3072, r3, r6 ## E)\
+   round_mov(TAB+2048, r7, r3 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r1 ## E;\
-   xorlTAB+1024(,r1,4),r6 ## E;\
-   xorlTAB(,r7,4),r3 ## E; \
+   round_xor(TAB+1024, r1, r6 ## E)\
+   round_xor(TAB, r7, r3 ## E) \
movzbl  r2 ## H,r1 ## E;\
movzbl  r2 ## L,r7 ## E;\
shrl$16,r2 ## E;\
-   xorlTAB+3072(,r1,4),r3 ## E;\
-   xorlTAB+2048(,r7,4),r4 ## E;\
+   round_xor(TAB+3072, r1, r3 ## E)\
+   round_xor(TAB+2048, r7, r4 ## E)\
movzbl  r2 ## H,r1 ## E;\
movzbl  r2 ## L,r2 ## E;\
xorlOFFSET+8(r8),rc ## E;   \
xorlOFFSET+12(r8),rd ## E;  \
-   xorlTAB+1024(,r1,4),r3 ## E;\
-   xorlTAB(,r2,4),r4 ## E;
+   round_xor(TAB+1024, r1, r3 ## E)\
+   round_xor(TAB, r2, r4 ## E)
 
 #define move_regs(r1,r2,r3,r4) \
movlr3 ## E,r1 ## E;\
diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index e762ef417562..4df029aa5fc1 100644

[Xen-devel] [PATCH v3 24/27] x86/mm: Make the x86 GOT read-only

[Thomas Garnier]

The GOT is changed during early boot when relocations are applied. Make
it read-only directly. This table exists only for PIE binary.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 include/asm-generic/vmlinux.lds.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index e373e2e10f6a..e5b0710fe693 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -314,6 +314,17 @@
__end_ro_after_init = .;
 #endif
 
+#ifdef CONFIG_X86_PIE
+#define RO_GOT_X86 \
+   .got: AT(ADDR(.got) - LOAD_OFFSET) {\
+   VMLINUX_SYMBOL(__start_got) = .;\
+   *(.got);\
+   VMLINUX_SYMBOL(__end_got) = .;  \
+   }
+#else
+#define RO_GOT_X86
+#endif
+
 /*
  * Read only Data
  */
@@ -370,6 +381,7 @@
__end_builtin_fw = .;   \
}   \
\
+   RO_GOT_X86  \
TRACEDATA   \
\
/* Kernel symbol table: Normal symbols */   \
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 16/27] compiler: Option to add PROVIDE_HIDDEN replacement for weak symbols

[Thomas Garnier]

Provide an option to have a PROVIDE_HIDDEN (linker script) entry for
each weak symbol. This option solve an error in x86_64 where the linker
optimizes pie generate code to be non-pie because --emit-relocs was used
instead of -pie (to reduce dynamic relocations).

Signed-off-by: Thomas Garnier 
---
 init/Kconfig|  7 +++
 scripts/link-vmlinux.sh | 14 ++
 2 files changed, 21 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index 0fc3a58d9f2f..2866cca86b4a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1954,6 +1954,13 @@ config ASN1
  inform it as to what tags are to be expected in a stream and what
  functions to call on what tags.
 
+config WEAK_PROVIDE_HIDDEN
+   bool
+   help
+ Generate linker script PROVIDE_HIDDEN entries for all weak symbols. It
+ allows to prevent non-pie code being replaced by the linker if the
+ emit-relocs option is used instead of pie (useful for x86_64 pie).
+
 source "kernel/Kconfig.locks"
 
 config ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 4bf811c09f59..f5d31119b9d7 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -142,6 +142,17 @@ kallsyms()
${CC} ${aflags} -c -o ${2} ${afile}
 }
 
+gen_weak_provide_hidden()
+{
+if [ -n "${CONFIG_WEAK_PROVIDE_HIDDEN}" ]; then
+local pattern="s/^\s\+ w \(\w\+\)$/PROVIDE_HIDDEN(\1 = .);/gp"
+echo -e "SECTIONS {\n. = _end;" > .tmp_vmlinux_hiddenld
+${NM} ${1} | sed -n "${pattern}" >> .tmp_vmlinux_hiddenld
+echo "}" >> .tmp_vmlinux_hiddenld
+LDFLAGS_vmlinux="${LDFLAGS_vmlinux} -T .tmp_vmlinux_hiddenld"
+fi
+}
+
 # Create map file with all symbols from ${1}
 # See mksymap for additional details
 mksysmap()
@@ -226,6 +237,9 @@ modpost_link vmlinux.o
 # modpost vmlinux.o to check for section mismatches
 ${MAKE} -f "${srctree}/scripts/Makefile.modpost" vmlinux.o
 
+# Generate weak linker script
+gen_weak_provide_hidden vmlinux.o
+
 kallsymso=""
 kallsyms_vmlinux=""
 if [ -n "${CONFIG_KALLSYMS}" ]; then
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 12/27] x86/paravirt: Adapt assembly for PIE support

[Thomas Garnier]

if PIE is enabled, switch the paravirt assembly constraints to be
compatible. The %c/i constrains generate smaller code so is kept by
default.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/paravirt_types.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 180bc0bff0fb..140747a98d94 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -337,9 +337,17 @@ extern struct pv_lock_ops pv_lock_ops;
 #define PARAVIRT_PATCH(x)  \
(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
 
+#ifdef CONFIG_X86_PIE
+#define paravirt_opptr_call "a"
+#define paravirt_opptr_type "p"
+#else
+#define paravirt_opptr_call "c"
+#define paravirt_opptr_type "i"
+#endif
+
 #define paravirt_type(op)  \
[paravirt_typenum] "i" (PARAVIRT_PATCH(op)),\
-   [paravirt_opptr] "i" (&(op))
+   [paravirt_opptr] paravirt_opptr_type (&(op))
 #define paravirt_clobber(clobber)  \
[paravirt_clobber] "i" (clobber)
 
@@ -395,7 +403,7 @@ int paravirt_disable_iospace(void);
  */
 #define PARAVIRT_CALL  \
ANNOTATE_RETPOLINE_SAFE \
-   "call *%c[paravirt_opptr];"
+   "call *%" paravirt_opptr_call "[paravirt_opptr];"
 
 /*
  * These macros are intended to wrap calls through one of the paravirt
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 06/27] x86/entry/64: Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/entry/entry_64.S| 18 --
 arch/x86/kernel/relocate_kernel_64.S |  8 +++-
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index c9648b287d7f..8638dca78191 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -191,7 +191,7 @@ ENTRY(entry_SYSCALL_64_trampoline)
 * spill RDI and restore it in a second-stage trampoline.
 */
pushq   %rdi
-   movq$entry_SYSCALL_64_stage2, %rdi
+   movabsq $entry_SYSCALL_64_stage2, %rdi
JMP_NOSPEC %rdi
 END(entry_SYSCALL_64_trampoline)
 
@@ -1279,7 +1279,8 @@ ENTRY(error_entry)
movl%ecx, %eax  /* zero extend */
cmpq%rax, RIP+8(%rsp)
je  .Lbstep_iret
-   cmpq$.Lgs_change, RIP+8(%rsp)
+   leaq.Lgs_change(%rip), %rcx
+   cmpq%rcx, RIP+8(%rsp)
jne .Lerror_entry_done
 
/*
@@ -1484,10 +1485,10 @@ ENTRY(nmi)
 * resume the outer NMI.
 */
 
-   movq$repeat_nmi, %rdx
+   leaqrepeat_nmi(%rip), %rdx
cmpq8(%rsp), %rdx
ja  1f
-   movq$end_repeat_nmi, %rdx
+   leaqend_repeat_nmi(%rip), %rdx
cmpq8(%rsp), %rdx
ja  nested_nmi_out
 1:
@@ -1541,7 +1542,8 @@ nested_nmi:
pushq   %rdx
pushfq
pushq   $__KERNEL_CS
-   pushq   $repeat_nmi
+   leaqrepeat_nmi(%rip), %rdx
+   pushq   %rdx
 
/* Put stack back */
addq$(6*8), %rsp
@@ -1580,7 +1582,11 @@ first_nmi:
addq$8, (%rsp)  /* Fix up RSP */
pushfq  /* RFLAGS */
pushq   $__KERNEL_CS/* CS */
-   pushq   $1f /* RIP */
+   pushq   $0  /* Futur return address */
+   pushq   %rax/* Save RAX */
+   leaq1f(%rip), %rax  /* RIP */
+   movq%rax, 8(%rsp)   /* Put 1f on return address */
+   popq%rax/* Restore RAX */
iretq   /* continues at repeat_nmi below */
UNWIND_HINT_IRET_REGS
 1:
diff --git a/arch/x86/kernel/relocate_kernel_64.S 
b/arch/x86/kernel/relocate_kernel_64.S
index a7227dfe1a2b..0c0fc259a4e2 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -208,11 +208,9 @@ identity_mapped:
movq%rax, %cr3
lea PAGE_SIZE(%r8), %rsp
callswap_pages
-   jmp *virtual_mapped_addr(%rip)
-
-   /* Absolute value for PIE support */
-virtual_mapped_addr:
-   .quad virtual_mapped
+   movabsq $virtual_mapped, %rax
+   pushq   %rax
+   ret
 
 virtual_mapped:
movqRSP(%r8), %rsp
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/acpi/wakeup_64.S | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
index 50b8ed0317a3..472659c0f811 100644
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -14,7 +14,7 @@
 * Hooray, we are in Long 64-bit mode (but still running in low memory)
 */
 ENTRY(wakeup_long64)
-   movqsaved_magic, %rax
+   movqsaved_magic(%rip), %rax
movq$0x123456789abcdef0, %rdx
cmpq%rdx, %rax
jne bogus_64_magic
@@ -25,14 +25,14 @@ ENTRY(wakeup_long64)
movw%ax, %es
movw%ax, %fs
movw%ax, %gs
-   movqsaved_rsp, %rsp
+   movqsaved_rsp(%rip), %rsp
 
-   movqsaved_rbx, %rbx
-   movqsaved_rdi, %rdi
-   movqsaved_rsi, %rsi
-   movqsaved_rbp, %rbp
+   movqsaved_rbx(%rip), %rbx
+   movqsaved_rdi(%rip), %rdi
+   movqsaved_rsi(%rip), %rsi
+   movqsaved_rbp(%rip), %rbp
 
-   movqsaved_rip, %rax
+   movqsaved_rip(%rip), %rax
jmp *%rax
 ENDPROC(wakeup_long64)
 
@@ -45,7 +45,7 @@ ENTRY(do_suspend_lowlevel)
xorl%eax, %eax
callsave_processor_state
 
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
movq%rsi, pt_regs_si(%rax)
@@ -64,13 +64,14 @@ ENTRY(do_suspend_lowlevel)
pushfq
popqpt_regs_flags(%rax)
 
-   movq$.Lresume_point, saved_rip(%rip)
+   leaq.Lresume_point(%rip), %rax
+   movq%rax, saved_rip(%rip)
 
-   movq%rsp, saved_rsp
-   movq%rbp, saved_rbp
-   movq%rbx, saved_rbx
-   movq%rdi, saved_rdi
-   movq%rsi, saved_rsi
+   movq%rsp, saved_rsp(%rip)
+   movq%rbp, saved_rbp(%rip)
+   movq%rbx, saved_rbx(%rip)
+   movq%rdi, saved_rdi(%rip)
+   movq%rsi, saved_rsi(%rip)
 
addq$8, %rsp
movl$3, %edi
@@ -82,7 +83,7 @@ ENTRY(do_suspend_lowlevel)
.align 4
 .Lresume_point:
/* We don't restore %rax, it must be 0 anyway */
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movqsaved_context_cr4(%rax), %rbx
movq%rbx, %cr4
movqsaved_context_cr3(%rax), %rbx
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 07/27] x86: pm-trace - Adapt assembly for PIE support

[Thomas Garnier]

Change assembly to use the new _ASM_MOVABS macro instead of _ASM_MOV for
the assembly to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/pm-trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pm-trace.h b/arch/x86/include/asm/pm-trace.h
index bfa32aa428e5..972070806ce9 100644
--- a/arch/x86/include/asm/pm-trace.h
+++ b/arch/x86/include/asm/pm-trace.h
@@ -8,7 +8,7 @@
 do {   \
if (pm_trace_enabled) { \
const void *tracedata;  \
-   asm volatile(_ASM_MOV " $1f,%0\n"   \
+   asm volatile(_ASM_MOVABS " $1f,%0\n"\
 ".section .tracedata,\"a\"\n"  \
 "1:\t.word %c1\n\t"\
 _ASM_PTR " %c2\n"  \
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 19/27] kvm: Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible. The new __ASM_MOVABS macro is used to
get the address of a symbol on both 32 and 64-bit with PIE support.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/kvm_host.h | 8 ++--
 arch/x86/kernel/kvm.c   | 6 --
 arch/x86/kvm/svm.c  | 4 ++--
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b27de80f5870..312a398465e8 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1389,9 +1389,13 @@ asmlinkage void kvm_spurious_fault(void);
".pushsection .fixup, \"ax\" \n" \
"667: \n\t" \
cleanup_insn "\n\t"   \
-   "cmpb $0, kvm_rebooting \n\t" \
+   "cmpb $0, kvm_rebooting" __ASM_SEL(,(%%rip)) " \n\t" \
"jne 668b \n\t"   \
-   __ASM_SIZE(push) " $666b \n\t"\
+   __ASM_SIZE(push) "$0 \n\t"  \
+   __ASM_SIZE(push) "%%" _ASM_AX " \n\t"   \
+   _ASM_MOVABS " $666b, %%" _ASM_AX "\n\t" \
+   _ASM_MOV " %%" _ASM_AX ", " __ASM_SEL(4,8) "(%%" _ASM_SP ") \n\t" \
+   __ASM_SIZE(pop) "%%" _ASM_AX " \n\t"\
"call kvm_spurious_fault \n\t"\
".popsection \n\t" \
_ASM_EXTABLE(666b, 667b)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 7867417cfaff..394c00f21f05 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -726,8 +726,10 @@ asm(
 ".global __raw_callee_save___kvm_vcpu_is_preempted;"
 ".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
 "__raw_callee_save___kvm_vcpu_is_preempted:"
-"movq  __per_cpu_offset(,%rdi,8), %rax;"
-"cmpb  $0, " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rax);"
+"leaq  __per_cpu_offset(%rip), %rax;"
+"movq  (%rax,%rdi,8), %rax;"
+"addq  " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rip), %rax;"
+"cmpb  $0, (%rax);"
 "setne %al;"
 "ret;"
 ".popsection");
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 220e5a89465a..2b0b25be5236 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -701,12 +701,12 @@ static u32 svm_msrpm_offset(u32 msr)
 
 static inline void clgi(void)
 {
-   asm volatile (__ex(SVM_CLGI));
+   asm volatile (__ex(SVM_CLGI) : :);
 }
 
 static inline void stgi(void)
 {
-   asm volatile (__ex(SVM_STGI));
+   asm volatile (__ex(SVM_STGI) : :);
 }
 
 static inline void invlpga(unsigned long addr, u32 asid)
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 13/27] x86/boot/64: Build head64.c as mcmodel large when PIE is enabled

[Thomas Garnier]

The __startup_64 function assumes all symbols have relocated addresses
instead of the current boot virtual address. PIE generated code favor
relative addresses making all virtual and physical address math incorrect.
If PIE is enabled, build head64.c as mcmodel large instead to ensure absolute
references on all memory access. Add a global __force_order variable required
when using a large model with read_cr* functions.

To build head64.c as mcmodel=large, disable the retpoline gcc flags.
This code is used at early boot and removed later, it doesn't need
retpoline mitigation.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/Makefile | 6 ++
 arch/x86/kernel/head64.c | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 02d6f5cf4e70..0f6da4b216e0 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -22,6 +22,12 @@ CFLAGS_REMOVE_early_printk.o = -pg
 CFLAGS_REMOVE_head64.o = -pg
 endif
 
+ifdef CONFIG_X86_PIE
+# Remove PIE and retpoline flags that are incompatible with mcmodel=large
+CFLAGS_REMOVE_head64.o += -fPIE -mindirect-branch=thunk-extern 
-mindirect-branch-register
+CFLAGS_head64.o = -mcmodel=large
+endif
+
 KASAN_SANITIZE_head$(BITS).o   := n
 KASAN_SANITIZE_dumpstack.o := n
 KASAN_SANITIZE_dumpstack_$(BITS).o := n
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 2d29e47c056e..fa661fb97127 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -64,6 +64,9 @@ EXPORT_SYMBOL(vmemmap_base);
 
 #define __head __section(.head.text)
 
+/* Required for read_cr3 when building as PIE */
+unsigned long __force_order;
+
 static void __head *fixup_pointer(void *ptr, unsigned long physaddr)
 {
return ptr - (void *)_text + (void *)physaddr;
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 08/27] x86/CPU: Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible. Use the new _ASM_MOVABS macro instead of
the 'mov $symbol, %dst' construct.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/processor.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index c119d423eacb..81ae6877df29 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -50,7 +50,7 @@ static inline void *current_text_addr(void)
 {
void *pc;
 
-   asm volatile("mov $1f, %0; 1:":"=r" (pc));
+   asm volatile(_ASM_MOVABS " $1f, %0; 1:":"=r" (pc));
 
return pc;
 }
@@ -718,6 +718,7 @@ static inline void sync_core(void)
: ASM_CALL_CONSTRAINT : : "memory");
 #else
unsigned int tmp;
+   unsigned long tmp2;
 
asm volatile (
UNWIND_HINT_SAVE
@@ -728,11 +729,13 @@ static inline void sync_core(void)
"pushfq\n\t"
"mov %%cs, %0\n\t"
"pushq %q0\n\t"
-   "pushq $1f\n\t"
+   "leaq 1f(%%rip), %1\n\t"
+   "pushq %1\n\t"
"iretq\n\t"
UNWIND_HINT_RESTORE
"1:"
-   : "=" (tmp), ASM_CALL_CONSTRAINT : : "cc", "memory");
+   : "=" (tmp), "=" (tmp2), ASM_CALL_CONSTRAINT
+   : : "cc", "memory");
 #endif
 }
 
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 02/27] x86: Use symbol name on bug table for PIE support

[Thomas Garnier]

Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 6804d6642767..3d690a4abf50 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -35,7 +35,7 @@ do {  
\
asm volatile("1:\t" ins "\n"\
 ".pushsection __bug_table,\"aw\"\n"\
 "2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"   \
-"\t"  __BUG_REL(%c0) "\t# bug_entry::file\n"   \
+"\t"  __BUG_REL(%P0) "\t# bug_entry::file\n"   \
 "\t.word %c1""\t# bug_entry::line\n"   \
 "\t.word %c2""\t# bug_entry::flags\n"  \
 "\t.org 2b+%c3\n"  \
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 11/27] x86/power/64: Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/power/hibernate_asm_64.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/hibernate_asm_64.S 
b/arch/x86/power/hibernate_asm_64.S
index ce8da3a0412c..6fdd7bbc3c33 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -24,7 +24,7 @@
 #include 
 
 ENTRY(swsusp_arch_suspend)
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
movq%rsi, pt_regs_si(%rax)
@@ -115,7 +115,7 @@ ENTRY(restore_registers)
movq%rax, %cr4;  # turn PGE back on
 
/* We don't restore %rax, it must be 0 anyway */
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movqpt_regs_sp(%rax), %rsp
movqpt_regs_bp(%rax), %rbp
movqpt_regs_si(%rax), %rsi
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 05/27] x86: relocate_kernel - Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/relocate_kernel_64.S | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/relocate_kernel_64.S 
b/arch/x86/kernel/relocate_kernel_64.S
index 11eda21eb697..a7227dfe1a2b 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -208,9 +208,11 @@ identity_mapped:
movq%rax, %cr3
lea PAGE_SIZE(%r8), %rsp
callswap_pages
-   movq$virtual_mapped, %rax
-   pushq   %rax
-   ret
+   jmp *virtual_mapped_addr(%rip)
+
+   /* Absolute value for PIE support */
+virtual_mapped_addr:
+   .quad virtual_mapped
 
 virtual_mapped:
movqRSP(%r8), %rsp
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 10/27] x86/boot/64: Adapt assembly for PIE support

[Thomas Garnier]

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Early at boot, the kernel is mapped at a temporary address while preparing
the page table. To know the changes needed for the page table with KASLR,
the boot code calculate the difference between the expected address of the
kernel and the one chosen by KASLR. It does not work with PIE because all
symbols in code are relatives. Instead of getting the future relocated
virtual address, you will get the current temporary mapping. The solution
is using global variables that will be relocated as expected.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/head_64.S | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 8344dd2f310a..7c8f7ce93b9e 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -89,8 +89,9 @@ startup_64:
popq%rsi
 
/* Form the CR3 value being sure to include the CR3 modifier */
-   addq$(early_top_pgt - __START_KERNEL_map), %rax
+   addq_early_top_pgt_offset(%rip), %rax
jmp 1f
+
 ENTRY(secondary_startup_64)
UNWIND_HINT_EMPTY
/*
@@ -119,7 +120,7 @@ ENTRY(secondary_startup_64)
popq%rsi
 
/* Form the CR3 value being sure to include the CR3 modifier */
-   addq$(init_top_pgt - __START_KERNEL_map), %rax
+   addq_init_top_offset(%rip), %rax
 1:
 
/* Enable PAE mode, PGE and LA57 */
@@ -137,7 +138,7 @@ ENTRY(secondary_startup_64)
movq%rax, %cr3
 
/* Ensure I am executing from virtual addresses */
-   movq$1f, %rax
+   movabs  $1f, %rax
ANNOTATE_RETPOLINE_SAFE
jmp *%rax
 1:
@@ -234,11 +235,12 @@ ENTRY(secondary_startup_64)
 *  REX.W + FF /5 JMP m16:64 Jump far, absolute indirect,
 *  address given in m16:64.
 */
-   pushq   $.Lafter_lret   # put return address on stack for unwinder
+   leaq.Lafter_lret(%rip), %rax
+   pushq   %rax# put return address on stack for unwinder
xorq%rbp, %rbp  # clear frame pointer
-   movqinitial_code(%rip), %rax
+   leaqinitial_code(%rip), %rax
pushq   $__KERNEL_CS# set correct cs
-   pushq   %rax# target address in negative space
+   pushq   (%rax)  # target address in negative space
lretq
 .Lafter_lret:
 END(secondary_startup_64)
@@ -342,6 +344,18 @@ END(early_idt_handler_common)
 GLOBAL(early_recursion_flag)
.long 0
 
+   /*
+* Position Independent Code takes only relative references in code
+* meaning a global variable address is relative to RIP and not its
+* future virtual address. Global variables can be used instead as they
+* are still relocated on the expected kernel mapping address.
+*/
+   .align 8
+_early_top_pgt_offset:
+   .quad early_top_pgt - __START_KERNEL_map
+_init_top_offset:
+   .quad init_top_pgt - __START_KERNEL_map
+
 #define NEXT_PAGE(name) \
.balign PAGE_SIZE; \
 GLOBAL(name)
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 04/27] x86: Add macro to get symbol address for PIE support

[Thomas Garnier]

Add a new _ASM_MOVABS macro to fetch a symbol address. It will be used
to replace "_ASM_MOV $, %dst" code construct that are not compatible
with PIE.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/asm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 219faaec51df..4492a35fad69 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -30,6 +30,7 @@
 #define _ASM_ALIGN __ASM_SEL(.balign 4, .balign 8)
 
 #define _ASM_MOV   __ASM_SIZE(mov)
+#define _ASM_MOVABS__ASM_SEL(movl, movabsq)
 #define _ASM_INC   __ASM_SIZE(inc)
 #define _ASM_DEC   __ASM_SIZE(dec)
 #define _ASM_ADD   __ASM_SIZE(add)
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 03/27] x86: Use symbol name in jump table for PIE support

[Thomas Garnier]

Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 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 8c0de4282659..dfdcdc39604a 100644
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -37,9 +37,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 + %c1 \n\t"
+   _ASM_PTR "1b, %l[l_yes], %P0 \n\t"
".popsection \n\t"
-   : :  "i" (key), "i" (branch) : : l_yes);
+   : :  "X" (&((char *)key)[branch]) : : l_yes);
 
return false;
 l_yes:
@@ -53,9 +53,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 + %c1 \n\t"
+   _ASM_PTR "1b, %l[l_yes], %P0 \n\t"
".popsection \n\t"
-   : :  "i" (key), "i" (branch) : : l_yes);
+   : :  "X" (&((char *)key)[branch]) : : l_yes);
 
return false;
 l_yes:
-- 
2.17.0.441.gb46fe60e1d-goog


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 00/27] x86: PIE support and option to extend KASLR randomization

[Thomas Garnier]

Changes:
 - patch v3:
   - Update on message to describe longer term PIE goal.
   - Minor change on ftrace if condition.
   - Changed code using xchgq.
 - patch v2:
   - Adapt patch to work post KPTI and compiler changes
   - Redo all performance testing with latest configs and compilers
   - Simplify mov macro on PIE (MOVABS now)
   - Reduce GOT footprint
 - patch v1:
   - Simplify ftrace implementation.
   - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
 - rfc v3:
   - Use --emit-relocs instead of -pie to reduce dynamic relocation space on
 mapped memory. It also simplifies the relocation process.
   - Move the start the module section next to the kernel. Remove the need for
 -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
   - Support for XEN PVH as 32-bit relocations can be ignored with
 --emit-relocs.
   - Support for GOT relocations previously done automatically with -pie.
   - Remove need for dynamic PLT in modules.
   - Support dymamic GOT for modules.
 - rfc v2:
   - Add support for global stack cookie while compiler default to fs without
 mcmodel=kernel
   - Change patch 7 to correctly jump out of the identity mapping on kexec load
 preserve.

These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G. The chosen range is the one currently
available, future changes will allow the kernel module to have a wider
randomization range.

Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
feedback for using -pie versus --emit-relocs and details on compiler code
generation.

The patches:
 - 1-3, 5-13, 18-19: Change in assembly code to be PIE compliant.
 - 4: Add a new _ASM_MOVABS macro to fetch a symbol address generically.
 - 14: Adapt percpu design to work correctly when PIE is enabled.
 - 15: Provide an option to default visibility to hidden except for key symbols.
   It removes errors between compilation units.
 - 16: Add PROVIDE_HIDDEN replacement on the linker script for weak symbols to
   reduce GOT footprint.
 - 17: Adapt relocation tool to handle PIE binary correctly.
 - 20: Add support for global cookie.
 - 21: Support ftrace with PIE (used on Ubuntu config).
 - 22: Add option to move the module section just after the kernel.
 - 23: Adapt module loading to support PIE with dynamic GOT.
 - 24: Make the GOT read-only.
 - 25: Add the CONFIG_X86_PIE option (off by default).
 - 26: Adapt relocation tool to generate a 64-bit relocation table.
 - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
   from 1G to 3G (off by default).

Performance/Size impact:

Size of vmlinux (Default configuration):
 File size:
 - PIE disabled: +0.18%
 - PIE enabled: -1.977% (less relocations)
 .text section:
 - PIE disabled: same
 - PIE enabled: same

Size of vmlinux (Ubuntu configuration):
 File size:
 - PIE disabled: +0.21%
 - PIE enabled: +10%
 .text section:
 - PIE disabled: same
 - PIE enabled: +0.001%

The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.

Hackbench (50% and 1600% on thread/process for pipe/sockets):
 - PIE disabled: no significant change (avg -/+ 0.5% on latest test).
 - PIE enabled: between -1% to +1% in average (default and Ubuntu config).

Kernbench (average of 10 Half and Optimal runs):
 Elapsed Time:
 - PIE disabled: no significant change (avg -0.5%)
 - PIE enabled: average -0.5% to +0.5%
 System Time:
 - PIE disabled: no significant change (avg -0.1%)
 - PIE enabled: average -0.4% to +0.4%.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303

diffstat:
 Documentation/x86/x86_64/mm.txt  |3 
 arch/x86/Kconfig |   45 ++
 arch/x86/Makefile|   58 
 arch/x86/boot/boot.h |2 
 arch/x86/boot/compressed/Makefile|5 
 arch/x86/boot/compressed/misc.c  |   10 +
 arch/x86/crypto/aes-x86_64-asm_64.S  |   45 --
 arch/x86/crypto/aesni-intel_asm.S|8 -
 arch/x86/crypto/aesni-intel_avx-x86_64.S |6 
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  |   42 +++---
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S |   44 +++---
 arch/x86/crypto/camellia-x86_64-asm_64.S |8 -
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S|   50 ---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S|   44 +++---
 arch/x86/crypto/des3_ede-asm_64.S|   96 +-
 arch/x86/crypto/ghash-clmulni-intel_asm.S|4 
 

Re: [Xen-devel] [PATCH v3 07/10] arm: make it possible to disable the SMMU driver

[Stefano Stabellini]

On Wed, 23 May 2018, Andrii Anisov wrote:
> Hello Stefano,
> 
> 
> On 23.05.18 03:25, Stefano Stabellini wrote:
> > Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: jbeul...@suse.com
> > 
> > ---
> > Changes in v3:
> > - rename SMMUv2 to ARM_SMMU
> > - improve help message
> > - use if ARM
> > 
> > Changes in v2:
> > - rename HAS_SMMUv2 to SMMUv2
> > - move SMMUv2 to xen/drivers/passthrough/Kconfig
> > ---
> >   xen/drivers/passthrough/Kconfig  | 12 
> >   xen/drivers/passthrough/arm/Makefile |  2 +-
> >   2 files changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/drivers/passthrough/Kconfig
> > b/xen/drivers/passthrough/Kconfig
> > index 8d90b67..a3c0649 100644
> > --- a/xen/drivers/passthrough/Kconfig
> > +++ b/xen/drivers/passthrough/Kconfig
> > @@ -1,3 +1,15 @@
> > config HAS_PASSTHROUGH
> > bool
> > +
> > +if ARM
> > +config ARM_SMMU
> > +   bool "ARM SMMUv1 and v2 driver"
> > +   default y
> Did you mean here "default n"? So in a platform selecting configs patch you
> silently skipping it for QEMU and RCAR3, but enabling for MPSOC?

I meant "default y" because I am only trying to introduce the options
in this patch series, I am not trying to change the defaults (yet).

In any case, even with "default y" it works as intended if you start
from tiny.config.

1) cp arch/arm/configs/tiny.conf .config
2) make olddefconfig
3) make menuconfig -> select RCAR3

the results is that ARM_SMMU will be disabled because it is already
disabled in tiny.config and CONFIG_RCAR3 won't enable it.


> > +   ---help---
> > + Support for implementations of the ARM System MMU architecture
> > + versions 1 and 2.
> > +
> > + Say Y here if your SoC includes an IOMMU device implementing the
> > + ARM SMMU architecture.
> > +endif
> > diff --git a/xen/drivers/passthrough/arm/Makefile
> > b/xen/drivers/passthrough/arm/Makefile
> > index f4cd26e..0156431 100644
> > --- a/xen/drivers/passthrough/arm/Makefile
> > +++ b/xen/drivers/passthrough/arm/Makefile
> > @@ -1,2 +1,2 @@
> >   obj-y += iommu.o
> > -obj-y += smmu.o
> > +obj-$(ARM_SMMU) += smmu.o

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [examine test] 123118: ALL FAIL

[osstest service owner]

flight 123118 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123118/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 examine-fiano02 hosts-allocate broken REGR. vs. 122584
 examine-arndale-metrocentre   2 hosts-allocate broken REGR. vs. 122584
 examine-italia1   2 hosts-allocate broken REGR. vs. 122584
 examine-godello1  2 hosts-allocate broken REGR. vs. 122584
 examine-pinot12 hosts-allocate broken REGR. vs. 122584
 examine-cubietruck-picasso2 hosts-allocate broken REGR. vs. 122584
 examine-elbling0  2 hosts-allocate broken REGR. vs. 122584
 examine-laxton0   2 hosts-allocate broken REGR. vs. 122584
 examine-cubietruck-braque 2 hosts-allocate broken REGR. vs. 122584
 examine-huxelrebe12 hosts-allocate broken REGR. vs. 122584
 examine-huxelrebe02 hosts-allocate broken REGR. vs. 122584
 examine-chardonnay1   2 hosts-allocate broken REGR. vs. 122584
 examine-godello0  2 hosts-allocate broken REGR. vs. 122584
 examine-arndale-bluewater 2 hosts-allocate broken REGR. vs. 122584
 examine-elbling1  2 hosts-allocate broken REGR. vs. 122584
 examine-baroque1  2 hosts-allocate broken REGR. vs. 122584
 examine-arndale-westfield 2 hosts-allocate broken REGR. vs. 122584
 examine-fiano12 hosts-allocate broken REGR. vs. 122584
 examine-arndale-lakeside  2 hosts-allocate broken REGR. vs. 122584
 examine-chardonnay0   2 hosts-allocate broken REGR. vs. 122584
 examine-baroque0  2 hosts-allocate broken REGR. vs. 122584
 examine-cubietruck-metzinger  2 hosts-allocate broken REGR. vs. 122584
 examine-pinot02 hosts-allocate broken REGR. vs. 122584

Tests which did not succeed, but are not blocking:
 examine-italia0   2 hosts-allocatebroken blocked in 122584
 examine-cubietruck-gleizes2 hosts-allocatebroken blocked in 122584
 examine-debina1   2 hosts-allocatebroken blocked in 122584
 examine-debina0   2 hosts-allocatebroken blocked in 122584

baseline version:
 flight   122584

jobs:
 examine-baroque0 fail
 examine-baroque1 fail
 examine-arndale-bluewaterfail
 examine-cubietruck-braquefail
 examine-chardonnay0  fail
 examine-chardonnay1  fail
 examine-debina0  fail
 examine-debina1  fail
 examine-elbling0 fail
 examine-elbling1 fail
 examine-fiano0   fail
 examine-fiano1   fail
 examine-cubietruck-gleizes   fail
 examine-godello0 fail
 examine-godello1 fail
 examine-huxelrebe0   fail
 examine-huxelrebe1   fail
 examine-italia0  fail
 examine-italia1  fail
 examine-arndale-lakeside fail
 examine-laxton0  fail
 examine-arndale-metrocentre  fail
 examine-cubietruck-metzinger fail
 examine-cubietruck-picasso   fail
 examine-pinot0   fail
 examine-pinot1   fail
 examine-arndale-westfieldfail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Push not applicable.

[Xen-devel] [RFC PATCH v3 2/9] include/linux/dma-mapping: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 should not be operated with
each others by OR.

Use GFP_NORMAL() to clear bottom 3 bits of GFP bitmaks.

Signed-off-by: Huaisheng Ye 
Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Christoph Hellwig 
---
 include/linux/dma-mapping.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f8ab1c0..8fe524d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -519,7 +519,7 @@ static inline void *dma_alloc_attrs(struct device *dev, 
size_t size,
return cpu_addr;
 
/* let the implementation decide on the zone to allocate from: */
-   flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
+   flag = GFP_NORMAL(flag);
 
if (!arch_dma_alloc_attrs(, ))
return NULL;
-- 
1.8.3.1



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 9/9] arch/x86/include/asm/page.h: update usage of movableflags

[Huaisheng Ye]

From: Huaisheng Ye 

GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.

Signed-off-by: Huaisheng Ye 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: x...@kernel.org 
Cc: Philippe Ombredanne 
Cc: Christoph Hellwig 
---
 arch/x86/include/asm/page.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
index 7555b48..a47f42d 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -35,7 +35,8 @@ static inline void copy_user_page(void *to, void *from, 
unsigned long vaddr,
 }
 
 #define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
-   alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
+   alloc_page_vma((movableflags ? GFP_HIGHUSER_MOVABLE : GFP_HIGHUSER) \
+   | __GFP_ZERO, vma, vaddr)
 #define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
 
 #ifndef __pa
-- 
1.8.3.1



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 10/10] xen: add cloc target

[Stefano Stabellini]

On Wed, 23 May 2018, Jan Beulich wrote:
> >>> On 22.05.18 at 22:08,  wrote:
> > On Tue, 22 May 2018, Jan Beulich wrote:
> >> >>> On 22.05.18 at 02:53,  wrote:
> >> > +$(eval tmpfile := $(shell mktemp))
> >> > +$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> >> > +$(eval path := $(dir $(f))) \
> >> > +$(eval name := $(shell cat $(f) | head -1 | cut -d " " 
> >> > -f 2)) \
> >> > +$(shell if test -f $(path)/$(name) ; then echo 
> >> > $(path)/$(name) >> $(tmpfile); fi;))
> >> > +cloc --list-file=$(tmpfile)
> >> > +rm $(tmpfile)
> >> 
> >> I think you also want to "rm -f $(tmpfile)" first thing in case a prior 
> >> "make cloc"
> >> was interrupted.
> > 
> > The issue is that tmpfile will be different the second time around
> > (mktemp returning a new name) so it is not quite possible to remove the
> > old tmpfile.
> 
> Oh, I'm sorry for the noise - I should have paid attention to the very
> first line of what is still quoted of your patch above.
> 
> Instead you then have the problem of the temporary file not being cleaned
> up when interrupting "make cloc". Granted there are many other cases
> where such files don't get cleaned up (judging from a look at my one /tmp),
> but it'd be nice if we didn't contribute to the problem.

Given that tmpfile will be quite small, I think it is best to keep using
mktemp and risk leaking it. However, if you prefer, I can switch to
using a well-known filename, such as "sourcelist" to avoid leaks in case
of Ctrl-C during make.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC v2] ViryaOS: proposal for a new Xen Project sub-project

[Stefano Stabellini]

Hi all,

Following up from previous conversations with the committers, I am
appending a proposal for a new Xen Project sub-project aimed at embedded
and IoT.

Sponsors are very welcome! :-)

Cheers,

Stefano


Changes in v2:
- clarify the x86_64 requirement

---

# ViryaOS

## Mission

To create and support open source Xen based tools that help users build
end-to-end secure embedded systems.


## The Problem

Xen enables highly secure, flexible architectures, suitable for widely
different embedded use-cases, from industrial to IoT and cloud. However,
putting a Xen based system together is still a complex endeavor. It is
even harder to configure it to be as secure as possible. In the Xen
ecosystem, we lack a unifying effort to help with the integration
challenges that anybody building Xen-based systems is facing. Setting up
a Xen based system takes too long and it is too hard for both users and
developers.

Today, many of us are spending time, effort and money to maintain their
own build systems and techniques for generating VM configurations,
resulting in significant duplication of efforts. These scripts and tools
could be more powerful if we worked on them together. It would cost
less to maintain them as a shared project, and eventually, they would be
more flexible and of better quality.


## The Solution

The solution is to unify our efforts behind a single open source
project, that will focus our collective development efforts on a shared
set of components.

The new project is ViryaOS, a multi-vendor open source collaborative
effort. ViryaOS will create a highly secure easy-to-use development
platform for Xen based systems aimed at IoT and embedded environments.
It will make it easier for engineers to develop secure Xen-based
platforms. In addition, ViryaOS will produce ready-to-use binary images
to help users and system integrators get started with Xen
on embedded systems.

ViryaOS will provide the space for us and others to collaborate. As a
unified group, it will be easier to approach hardware vendors and
partners to discuss support for ViryaOS.

Users will be able to build and deploy Xen-based disaggregated
architectures quickly and easily on x86 and ARM SoCs. ViryaOS will support
as many hardware platforms as possible, as many guest operating systems
as possible (including RTOSes and proprietary OSes), and highly
heterogeneous environments. ViryaOS will meet low power consumption
requirements.

ViryaOS will be secure out of the box. Unlike traditional operating
system designs based on a monolithic kernel, ViryaOS takes a microkernel
approach. ViryaOS will come with driver and service domains. The
security and manageability of the platform are achieved through security
by compartmentalization and privilege separation to minimize the attack
surface of the "supervisor" component (the part of the system capable of
unconstrained access to the underlying hardware).

All workloads will be supported. Virtual machines, containers, baremetal
applications and unikernels will all be first-class "applications"
running on ViryaOS. ViryaOS will support running containers natively and
securely by transparently spawning Xen virtual machines for isolation.


## Build and Output

ViryaOS will come with the tools to build Xen, Dom0, multiple VMs (with
or without device assignement) and assemble the complete system. The
build will rely on containers to shorten the build time and to make it
easier to reuse any single component. The output will include the
following binaries:

* Xen
* the Dom0 kernel (Linux)
* the Dom0 filesystem
* a disaggregated set of Service Domains, including their kernels,
  disk images and configurations (Service Domains include drivers
  domains and management VMs)
* any number of user-provided containers and VMs

The result will be a ready-to-use system image with all the pieces
already included. The image will be small, suitable for embedded systems
and IoT.

Users will be able to select different components and configurations at
build time, resulting in different outputs. Cross-compilation will be
supported.

ViryaOS will be able to use Yocto and/or existing distros such as Alpine
Linux to build some, or all, of its components. Anything could be used
as long as it can be built inside a container and the output follows a
specified format.

As the key enabler for Service Domains, device assignment will be
supported on both ARM and x86 to the best of the capabilities of the
hardware. The image will contain all the necessary configurations
(device tree manipulations, Xen command line arguments, etc) to make
device assignment work out of the box.


## Security

Security is one of ViryaOS's key attributes. The hardware capabilities
can differ for different boards, with some having TPM support and other
TEE (trusted execution environment) support. When the hardware supports
it, ViryaOS will use secure/measured boot on Intel and ARM, using the
best technologies available in hardware (such as Intel 

[Xen-devel] Commit moratorium for letting osstest catch up

[Juergen Gross]

Committers,

Please don't push any new patch to staging because osstest should
catch up to do a push.

Another email will be sent once the moratorium is lifted.


Juergen Gross

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 07/10] arm: make it possible to disable the SMMU driver

[Andrii Anisov]

Hello Stefano,


On 23.05.18 03:25, Stefano Stabellini wrote:

Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com

---
Changes in v3:
- rename SMMUv2 to ARM_SMMU
- improve help message
- use if ARM

Changes in v2:
- rename HAS_SMMUv2 to SMMUv2
- move SMMUv2 to xen/drivers/passthrough/Kconfig
---
  xen/drivers/passthrough/Kconfig  | 12 
  xen/drivers/passthrough/arm/Makefile |  2 +-
  2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index 8d90b67..a3c0649 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -1,3 +1,15 @@
  
  config HAS_PASSTHROUGH

bool
+
+if ARM
+config ARM_SMMU
+   bool "ARM SMMUv1 and v2 driver"
+   default y
Did you mean here "default n"? So in a platform selecting configs patch 
you silently skipping it for QEMU and RCAR3, but enabling for MPSOC?



+   ---help---
+ Support for implementations of the ARM System MMU architecture
+ versions 1 and 2.
+
+ Say Y here if your SoC includes an IOMMU device implementing the
+ ARM SMMU architecture.
+endif
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..0156431 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,2 @@
  obj-y += iommu.o
-obj-y += smmu.o
+obj-$(ARM_SMMU) += smmu.o


--

*Andrii Anisov*



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.9-testing test] 123009: regressions - FAIL

[osstest service owner]

flight 123009 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123009/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail REGR. vs. 
122512

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 
fail in 122960 pass in 123009
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 122960
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
122960

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail blocked in 
122512
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 122960 blocked in 
122512
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 122960 like 122417
 test-amd64-i386-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail in 122960 
like 122417
 test-amd64-i386-xl-qemut-ws16-amd64 14 guest-localmigrate fail in 122960 like 
122472
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop  fail in 122960 like 122472
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 122960 like 122512
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail in 122960 like 122512
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 122472
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 122472
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122472
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122512
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 122512
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 122512
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 

Re: [Xen-devel] [PATCH 0/6] arm: more kconfig configurability and small default configs

[Andrii Anisov]

Hello Stefano,


On 22.05.18 02:45, Stefano Stabellini wrote:

I am not sure I understand your suggestion. But I think we are heading
in the direction you are hinting toward with Juergen's suggestion to
only keep kconfig options that are not "default". If you give a look at
v2, the rcar3.config is smaller and doesn't have much more than the
basic drivers for the platform.


What I did mean is closer to v3. With one more hint about a selecting 
platform code one can find in xen/arch/arm/platforms.

Something like:

diff --git a/xen/arch/arm/platforms/Makefile 
b/xen/arch/arm/platforms/Makefile

index 53a47e4..c420318 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -7,4 +7,4 @@ obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-y += sunxi.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
-obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_MPSOC) += xilinx-zynqmp.o

Though, RCAR gen3 does not have the platform code yet. So nothing to 
select for it now ;)


--

*Andrii Anisov*



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 7/9] mm/zsmalloc: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.

__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE flag.

With GFP_ZONE_TABLE, __GFP_HIGHMEM ORing __GFP_MOVABLE means gfp_zone
should return ZONE_MOVABLE. In order to keep that compatible with
GFP_ZONE_TABLE, Use GFP_NORMAL_UNMOVABLE() to clear bottom 4 bits of
GFP bitmaks.

Signed-off-by: Huaisheng Ye 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Sergey Senozhatsky 
Cc: Christoph Hellwig 
---
 mm/zsmalloc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 61cb05d..e250c69 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -345,7 +345,7 @@ static void destroy_cache(struct zs_pool *pool)
 static unsigned long cache_alloc_handle(struct zs_pool *pool, gfp_t gfp)
 {
return (unsigned long)kmem_cache_alloc(pool->handle_cachep,
-   gfp & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
+   GFP_NORMAL_UNMOVABLE(gfp));
 }
 
 static void cache_free_handle(struct zs_pool *pool, unsigned long handle)
@@ -356,7 +356,7 @@ static void cache_free_handle(struct zs_pool *pool, 
unsigned long handle)
 static struct zspage *cache_alloc_zspage(struct zs_pool *pool, gfp_t flags)
 {
return kmem_cache_alloc(pool->zspage_cachep,
-   flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
+   GFP_NORMAL_UNMOVABLE(flags));
 }
 
 static void cache_free_zspage(struct zs_pool *pool, struct zspage *zspage)
-- 
1.8.3.1



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [libvirt test] 123010: tolerable all pass - PUSHED

[osstest service owner]

flight 123010 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123010/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122962
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122962
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122962
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  e565b9cd0cc9907201ce1e3203be10bb0579e8fa
baseline version:
 libvirt  d3f4fc8684edc2b2fb41789817455e7412296a78

Last test of basis   122962  2018-05-19 01:18:16 Z4 days
Testing same since   123010  2018-05-21 08:08:08 Z2 days1 attempts


People who touched revisions under test:
  Ján Tomko 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To 

[Xen-devel] [RFC PATCH v3 5/9] drivers/block/zram/zram_drv: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.

__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE flag.

With GFP_ZONE_TABLE, __GFP_HIGHMEM ORing __GFP_MOVABLE means gfp_zone
should return ZONE_MOVABLE. In order to keep that compatible with
GFP_ZONE_TABLE, replace (__GFP_HIGHMEM | __GFP_MOVABLE) with
__GFP_ZONE_MOVABLE.

Signed-off-by: Huaisheng Ye 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Sergey Senozhatsky 
Cc: Christoph Hellwig 
---
 drivers/block/zram/zram_drv.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 0f3fadd..1bb5ca8 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1004,14 +1004,12 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec,
handle = zs_malloc(zram->mem_pool, comp_len,
__GFP_KSWAPD_RECLAIM |
__GFP_NOWARN |
-   __GFP_HIGHMEM |
-   __GFP_MOVABLE);
+   __GFP_ZONE_MOVABLE);
if (!handle) {
zcomp_stream_put(zram->comp);
atomic64_inc(>stats.writestall);
handle = zs_malloc(zram->mem_pool, comp_len,
-   GFP_NOIO | __GFP_HIGHMEM |
-   __GFP_MOVABLE);
+   GFP_NOIO | __GFP_ZONE_MOVABLE);
if (handle)
goto compress_again;
return -ENOMEM;
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 9/9] arch/x86/include/asm/page.h: update usage of movableflags

[Huaisheng Ye]

From: Huaisheng Ye 

GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.

Signed-off-by: Huaisheng Ye 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: x...@kernel.org 
Cc: Philippe Ombredanne 
Cc: Christoph Hellwig 
---
 arch/x86/include/asm/page.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
index 7555b48..a47f42d 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -35,7 +35,8 @@ static inline void copy_user_page(void *to, void *from, 
unsigned long vaddr,
 }
 
 #define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
-   alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
+   alloc_page_vma((movableflags ? GFP_HIGHUSER_MOVABLE : GFP_HIGHUSER) \
+   | __GFP_ZERO, vma, vaddr)
 #define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
 
 #ifndef __pa
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 8/9] include/linux/highmem.h: update usage of movableflags

[Huaisheng Ye]

From: Huaisheng Ye 

GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.

Signed-off-by: Huaisheng Ye 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: Thomas Gleixner 
Cc: Philippe Ombredanne 
Cc: Christoph Hellwig 
---
 include/linux/highmem.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 0690679..5383c9e 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -159,8 +159,8 @@ static inline void clear_user_highpage(struct page *page, 
unsigned long vaddr)
struct vm_area_struct *vma,
unsigned long vaddr)
 {
-   struct page *page = alloc_page_vma(GFP_HIGHUSER | movableflags,
-   vma, vaddr);
+   struct page *page = alloc_page_vma(movableflags ?
+   GFP_HIGHUSER_MOVABLE : GFP_HIGHUSER, vma, vaddr);
 
if (page)
clear_user_highpage(page, vaddr);
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 7/9] mm/zsmalloc: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.

__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE flag.

With GFP_ZONE_TABLE, __GFP_HIGHMEM ORing __GFP_MOVABLE means gfp_zone
should return ZONE_MOVABLE. In order to keep that compatible with
GFP_ZONE_TABLE, Use GFP_NORMAL_UNMOVABLE() to clear bottom 4 bits of
GFP bitmaks.

Signed-off-by: Huaisheng Ye 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Sergey Senozhatsky 
Cc: Christoph Hellwig 
---
 mm/zsmalloc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 61cb05d..e250c69 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -345,7 +345,7 @@ static void destroy_cache(struct zs_pool *pool)
 static unsigned long cache_alloc_handle(struct zs_pool *pool, gfp_t gfp)
 {
return (unsigned long)kmem_cache_alloc(pool->handle_cachep,
-   gfp & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
+   GFP_NORMAL_UNMOVABLE(gfp));
 }
 
 static void cache_free_handle(struct zs_pool *pool, unsigned long handle)
@@ -356,7 +356,7 @@ static void cache_free_handle(struct zs_pool *pool, 
unsigned long handle)
 static struct zspage *cache_alloc_zspage(struct zs_pool *pool, gfp_t flags)
 {
return kmem_cache_alloc(pool->zspage_cachep,
-   flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
+   GFP_NORMAL_UNMOVABLE(flags));
 }
 
 static void cache_free_zspage(struct zs_pool *pool, struct zspage *zspage)
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/9] x86/vmx: API improvements for MSR load/save infrastructure

[Andrew Cooper]

On 23/05/18 17:01, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:38PM +0100, Andrew Cooper wrote:
>> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
>> b/xen/include/asm-x86/hvm/vmx/vmcs.h
>> index 06c3179..c8a1f89 100644
>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
>> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
>> @@ -514,9 +514,6 @@ enum vmcs_field {
>>  
>>  #define VMCS_VPID_WIDTH 16
>>  
>> -#define VMX_GUEST_MSR 0
>> -#define VMX_HOST_MSR  1
>> -
>>  /* VM Instruction error numbers */
>>  enum vmx_insn_errno
>>  {
>> @@ -534,6 +531,54 @@ enum vmx_insn_errno
>>  VMX_INSN_FAIL_INVALID  = ~0,
>>  };
>>  
>> +/* MSR load/save list infrastructure. */
>> +enum vmx_msr_list_type {
>> +VMX_MSR_HOST,
>> +VMX_MSR_GUEST,
>> +};
>> +
>> +int vmx_add_msr(uint32_t msr, enum vmx_msr_list_type type);
>> +
>> +static inline int vmx_add_host_load_msr(uint32_t msr)
>> +{
>> +return vmx_add_msr(msr, VMX_MSR_HOST);
>> +}
>> +
>> +static inline int vmx_add_guest_msr(uint32_t msr)
>> +{
>> +return vmx_add_msr(msr, VMX_MSR_GUEST);
>> +}
>> +
>> +struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum vmx_msr_list_type 
>> type);
>> +
>> +static inline int vmx_read_guest_msr(uint32_t msr, uint64_t *val)
>> +{
>> +struct vmx_msr_entry *ent;
> const
>
> Also I would probably do:
>
> {
> const struct vmx_msr_entry *ent = vmx_find_msr(msr, VMX_MSR_GUEST);
>
> if ( !ent )
> return -ESRCH;
>
> *val = ent->data;
> return 0;
> }

Done.

>
> With the const:
>
> Reviewed-by: Roger Pau Monné 

Thanks,

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 1/2] xen/PVH: Set up GS segment for stack canary

[Boris Ostrovsky]

On 05/23/2018 11:41 AM, Jan Beulich wrote:
 On 23.05.18 at 16:30,  wrote:
>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>>  /* 64-bit entry point. */
>>  .code64
>>  1:
>> +/* Set base address in stack canary descriptor. */
>> +mov $MSR_GS_BASE,%ecx
>> +mov $_pa(canary), %rax
>> +xor %rdx, %rdx
> Why rax and rdx instead of eax and edx? In the former case, the
> relocation produced might confuse whatever entity processing it
> (it'll have a sign-extended 32-bit quantity to deal with, which
> wouldn't allow representing an address in the [2Gb, 4Gb) range).
> In the latter case, while surely neither performance nor code size
> matter much here, it's still a bad precedent (people copy-and-paste
> code all the time): Zero-ing of registers should generally use the
> 32-bit forms of the insn. Gas has actually gained an optimization
> mode recently (upon request from Linus and the x86 maintainers)
> to silently "repair" such inefficiencies.


Sure, I can replace these two with 32-bit variants. If there are no
other comments I won't re-send this again.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 4/9] fs/btrfs/extent_io: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MASK to replace (__GFP_DMA32 | __GFP_HIGHMEM).

In function alloc_extent_state, it is obvious that __GFP_DMA is not
the expecting zone type.

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 should not be operated with
each others by OR.

Use GFP_NORMAL() to clear bottom 3 bits of GFP bitmaks.

Signed-off-by: Huaisheng Ye 
Cc: Chris Mason 
Cc: Josef Bacik 
Cc: David Sterba 
Cc: Christoph Hellwig 
---
 fs/btrfs/extent_io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index e99b329..f41fc61 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -220,7 +220,7 @@ static struct extent_state *alloc_extent_state(gfp_t mask)
 * The given mask might be not appropriate for the slab allocator,
 * drop the unsupported bits
 */
-   mask &= ~(__GFP_DMA32|__GFP_HIGHMEM);
+   mask = GFP_NORMAL(mask);
state = kmem_cache_alloc(extent_state_cache, mask);
if (!state)
return state;
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

On 5/18/2018 4:31 AM, Paolo Bonzini wrote:

On 16/05/2018 22:27, Maran Wilson wrote:

Friendly ping. I am hopeful one of the x86 and/or KVM maintainers has a
few cycles to spare to look this over.

And thanks to everyone who has helped thus far by providing valuable
feedback and reviewing.

    https://lkml.org/lkml/2018/4/16/1002

KVM bits look fine.  This would be the right time to post the QEMU
patches...


Thanks Paolo. Yes, we will have the Qemu patches out soon. It is being 
actively worked. We have had one implementation in place, but decided to 
re-implement things slightly based on some preliminary feedback before 
sending it out to the wider community.


Thanks,
-Maran


Paolo



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

[Andrew Cooper]

On 23/05/18 17:39, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote:
>> Instead of having multiple algorithms searching the MSR lists, implement a
>> single one.  It has the semantics required by vmx_add_msr(), to identify the
>> position in which an MSR should live, if it isn't already present.
>>
>> There will be a marginal improvement for vmx_find_msr() by avoiding the
>> function pointer calls to vmx_msr_entry_key_cmp(), and a major improvement 
>> for
>> vmx_add_msr() by using a binary search instead of a linear search.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Jun Nakajima 
>> CC: Kevin Tian 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> ---
>>  xen/arch/x86/hvm/vmx/vmcs.c | 42 --
>>  1 file changed, 28 insertions(+), 14 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>> index f557857..e4acdc1 100644
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -1276,24 +1276,36 @@ static int construct_vmcs(struct vcpu *v)
>>  return 0;
>>  }
>>  
>> -static int vmx_msr_entry_key_cmp(const void *key, const void *elt)
>> +/*
>> + * Search an MSR list looking for an MSR entry, or the slot in which it 
>> should
>> + * live (to keep the data sorted) if an entry is not found.
>> + *
>> + * The return pointer is guarenteed to be bounded by start and end.  
>> However,
>> + * it may point at end, and may be invalid for the caller to dereference.
>> + */
>> +static struct vmx_msr_entry *locate_msr_entry(
>> +struct vmx_msr_entry *start, struct vmx_msr_entry *end, uint32_t msr)
>>  {
>> -const u32 *msr = key;
>> -const struct vmx_msr_entry *entry = elt;
>> +while ( start < end )
>> +{
>> +struct vmx_msr_entry *mid = start + (end - start) / 2;
>>  
>> -if ( *msr > entry->index )
>> -return 1;
>> -if ( *msr < entry->index )
>> -return -1;
>> +if ( msr < mid->index )
>> +end = mid;
>> +else if ( msr > mid->index )
>> +start = mid + 1;
>> +else
>> +return mid;
>> +}
> This is basically an open coded version of bsearch, isn't there anyway
> to adapt the current bsearch so that it could be used for both
> vmx_find_msr and vmx_add_msr?
>
> I know there will be a performance penalty for using a function
> pointer for the comparator function, but this looks like code
> duplication to me.

A third use appears in a later patch.  bsearch() doesn't have the
described property on a miss, which is necessary to maintain the lists.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/9] x86/vmx: Internal cleanup for MSR load/save infrastructure

[Andrew Cooper]

On 23/05/18 17:28, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:39PM +0100, Andrew Cooper wrote:
>>  * Use an arch_vmx_struct local variable to reduce later code volume.
>>  * Use start/total instead of msr_area/msr_count.  This is in preparation for
>>more finegrained handling with later changes.
>>  * Use ent/end pointers (again for preparation), and to make the 
>> vmx_add_msr()
>>logic easier to follow.
>>  * Make the memory allocation block of vmx_add_msr() unlikely, and calculate
>>virt_to_maddr() just once.
>>
>> No practical change to functionality.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Jun Nakajima 
>> CC: Kevin Tian 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> ---
>>  xen/arch/x86/hvm/vmx/vmcs.c | 74 
>> -
>>  1 file changed, 40 insertions(+), 34 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>> index a5dcf5c..f557857 100644
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -1292,48 +1292,50 @@ static int vmx_msr_entry_key_cmp(const void *key, 
>> const void *elt)
>>  struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum vmx_msr_list_type 
>> type)
>>  {
>>  struct vcpu *curr = current;
>> -unsigned int msr_count;
>> -struct vmx_msr_entry *msr_area = NULL;
>> +struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;
> curr is used here only, so you can use current and get rid of the curr
> local variable?

curr disappears in patch 4 "x86/vmx: Support remote access to the MSR
lists", when v starts getting passed in from the outside.

>
>> +struct vmx_msr_entry *start = NULL;
>> +unsigned int total;
>>  
>>  switch ( type )
>>  {
>>  case VMX_MSR_HOST:
>> -msr_count = curr->arch.hvm_vmx.host_msr_count;
>> -msr_area = curr->arch.hvm_vmx.host_msr_area;
>> +start= arch_vmx->host_msr_area;
>> +total= arch_vmx->host_msr_count;
>>  break;
>>  
>>  case VMX_MSR_GUEST:
>> -msr_count = curr->arch.hvm_vmx.msr_count;
>> -msr_area = curr->arch.hvm_vmx.msr_area;
>> +start= arch_vmx->msr_area;
>> +total= arch_vmx->msr_count;
> Not that I think is wrong, but why are you adding the extra spaces
> after the variable name? Those assignments will already be aligned
> because start and total names have the same length.

There are changes in later patches, for which this is the correct
indentation.

>
>>  break;
>>  
>>  default:
>>  ASSERT_UNREACHABLE();
>>  }
>>  
>> -if ( msr_area == NULL )
>> +if ( !start )
>>  return NULL;
>>  
>> -return bsearch(, msr_area, msr_count, sizeof(struct vmx_msr_entry),
>> +return bsearch(, start, total, sizeof(struct vmx_msr_entry),
>> vmx_msr_entry_key_cmp);
>>  }
>>  
>>  int vmx_add_msr(uint32_t msr, enum vmx_msr_list_type type)
>>  {
>>  struct vcpu *curr = current;
> curr seems to be used only once below in order to get hvm_vmx? In
> which case it could be removed.
>
>> -unsigned int idx, *msr_count;
>> -struct vmx_msr_entry **msr_area, *msr_area_elem;
>> +struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;
>> +struct vmx_msr_entry **ptr, *start = NULL, *ent, *end;
> Do you really need to initialize start here? It seems like it's
> unconditionally set to *ptr before any usage.

Yes, for safety through the default case in release builds.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 3/9] drivers/xen/swiotlb-xen: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM).

In function xen_swiotlb_alloc_coherent, it is obvious that __GFP_DMA32
is not the expecting zone type.

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 should not be operated with
each others by OR.

Use GFP_NORMAL() to clear bottom 3 bits of GFP bitmaks.

Signed-off-by: Huaisheng Ye 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Christoph Hellwig 
---
 drivers/xen/swiotlb-xen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index e1c6089..359 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -301,7 +301,7 @@ int __ref xen_swiotlb_init(int verbose, bool early)
* machine physical layout.  We can't allocate highmem
* because we can't return a pointer to it.
*/
-   flags &= ~(__GFP_DMA | __GFP_HIGHMEM);
+   flags = GFP_NORMAL(flags);
 
/* On ARM this function returns an ioremap'ped virtual address for
 * which virt_to_phys doesn't return the corresponding physical
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

[Roger Pau Monné]

On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote:
> Instead of having multiple algorithms searching the MSR lists, implement a
> single one.  It has the semantics required by vmx_add_msr(), to identify the
> position in which an MSR should live, if it isn't already present.
> 
> There will be a marginal improvement for vmx_find_msr() by avoiding the
> function pointer calls to vmx_msr_entry_key_cmp(), and a major improvement for
> vmx_add_msr() by using a binary search instead of a linear search.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> ---
>  xen/arch/x86/hvm/vmx/vmcs.c | 42 --
>  1 file changed, 28 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index f557857..e4acdc1 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1276,24 +1276,36 @@ static int construct_vmcs(struct vcpu *v)
>  return 0;
>  }
>  
> -static int vmx_msr_entry_key_cmp(const void *key, const void *elt)
> +/*
> + * Search an MSR list looking for an MSR entry, or the slot in which it 
> should
> + * live (to keep the data sorted) if an entry is not found.
> + *
> + * The return pointer is guarenteed to be bounded by start and end.  However,
> + * it may point at end, and may be invalid for the caller to dereference.
> + */
> +static struct vmx_msr_entry *locate_msr_entry(
> +struct vmx_msr_entry *start, struct vmx_msr_entry *end, uint32_t msr)
>  {
> -const u32 *msr = key;
> -const struct vmx_msr_entry *entry = elt;
> +while ( start < end )
> +{
> +struct vmx_msr_entry *mid = start + (end - start) / 2;
>  
> -if ( *msr > entry->index )
> -return 1;
> -if ( *msr < entry->index )
> -return -1;
> +if ( msr < mid->index )
> +end = mid;
> +else if ( msr > mid->index )
> +start = mid + 1;
> +else
> +return mid;
> +}

This is basically an open coded version of bsearch, isn't there anyway
to adapt the current bsearch so that it could be used for both
vmx_find_msr and vmx_add_msr?

I know there will be a performance penalty for using a function
pointer for the comparator function, but this looks like code
duplication to me.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 2/9] include/linux/dma-mapping: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 should not be operated with
each others by OR.

Use GFP_NORMAL() to clear bottom 3 bits of GFP bitmaks.

Signed-off-by: Huaisheng Ye 
Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Christoph Hellwig 
---
 include/linux/dma-mapping.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f8ab1c0..8fe524d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -519,7 +519,7 @@ static inline void *dma_alloc_attrs(struct device *dev, 
size_t size,
return cpu_addr;
 
/* let the implementation decide on the zone to allocate from: */
-   flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
+   flag = GFP_NORMAL(flag);
 
if (!arch_dma_alloc_attrs(, ))
return NULL;
-- 
1.8.3.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 0/9] get rid of GFP_ZONE_TABLE/BAD

[Huaisheng Ye]

From: Huaisheng Ye 

Changes since v2: [2]
* According to Christoph's suggestion, rebase patches to current
  mainline from v4.16.

* Follow the advice of Matthew, create macros like GFP_NORMAL and
  GFP_NORMAL_UNMOVABLE to clear bottom 3 and 4 bits of GFP bitmask.

* Delete some patches because of kernel updating.

[2]: https://marc.info/?l=linux-mm=152691610014027=2

Tested by Lenovo Thinksystem server.

Initmem setup node 0 [mem 0x1000-0x00043fff]
[0.00] On node 0 totalpages: 4111666
[0.00]   DMA zone: 64 pages used for memmap
[0.00]   DMA zone: 23 pages reserved
[0.00]   DMA zone: 3999 pages, LIFO batch:0
[0.00] mminit::memmap_init Initialising map node 0 zone 0 pfns 1 -> 
4096 
[0.00]   DMA32 zone: 10935 pages used for memmap
[0.00]   DMA32 zone: 699795 pages, LIFO batch:31
[0.00] mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 
1048576
[0.00]   Normal zone: 53248 pages used for memmap
[0.00]   Normal zone: 3407872 pages, LIFO batch:31
[0.00] mminit::memmap_init Initialising map node 0 zone 2 pfns 1048576 
-> 4456448
[0.00] mminit::memmap_init Initialising map node 0 zone 3 pfns 1 -> 
4456448
[0.00] Initmem setup node 1 [mem 0x00238000-0x00277fff]
[0.00] On node 1 totalpages: 4194304
[0.00]   Normal zone: 65536 pages used for memmap
[0.00]   Normal zone: 4194304 pages, LIFO batch:31
[0.00] mminit::memmap_init Initialising map node 1 zone 2 pfns 37224448 
-> 41418752
[0.00] mminit::memmap_init Initialising map node 1 zone 3 pfns 37224448 
-> 41418752
...
[0.00] mminit::zonelist general 0:DMA = 0:DMA
[0.00] mminit::zonelist general 0:DMA32 = 0:DMA32 0:DMA
[0.00] mminit::zonelist general 0:Normal = 0:Normal 0:DMA32 0:DMA 
1:Normal
[0.00] mminit::zonelist thisnode 0:DMA = 0:DMA
[0.00] mminit::zonelist thisnode 0:DMA32 = 0:DMA32 0:DMA
[0.00] mminit::zonelist thisnode 0:Normal = 0:Normal 0:DMA32 0:DMA
[0.00] mminit::zonelist general 1:Normal = 1:Normal 0:Normal 0:DMA32 
0:DMA
[0.00] mminit::zonelist thisnode 1:Normal = 1:Normal
[0.00] Built 2 zonelists, mobility grouping on.  Total pages: 8176164
[0.00] Policy zone: Normal
[0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.17.0-rc6-gfp09+ 
root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap 
debug 
LANG=en_US.UTF-8 mminit_loglevel=4 console=tty0 console=ttyS0,115200n8 
memblock=debug
earlyprintk=serial,0x3f8,115200

---

Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.

Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks,
the bottom three bits of GFP mask is reserved for storing encoded
zone number.

The encoding method is XOR. Get zone number from enum zone_type,
then encode the number with ZONE_NORMAL by XOR operation.
The goal is to make sure ZONE_NORMAL can be encoded to zero. So,
the compatibility can be guaranteed, such as GFP_KERNEL and GFP_ATOMIC
can be used as before.

Reserve __GFP_MOVABLE in bit 3, so that it can continue to be used as
a flag. Same as before, __GFP_MOVABLE respresents movable migrate type
for ZONE_DMA, ZONE_DMA32, and ZONE_NORMAL. But when it is enabled with
__GFP_HIGHMEM, ZONE_MOVABLE shall be returned instead of ZONE_HIGHMEM.
__GFP_ZONE_MOVABLE is created to realize it.

With this patch, just enabling __GFP_MOVABLE and __GFP_HIGHMEM is not
enough to get ZONE_MOVABLE from gfp_zone. All callers should use
GFP_HIGHUSER_MOVABLE or __GFP_ZONE_MOVABLE directly to achieve that.

Decode zone number directly from bottom three bits of flags in gfp_zone.
The theory of encoding and decoding is,
A ^ B ^ B = A

Changes since v1:[1]

* Create __GFP_ZONE_MOVABLE and modify GFP_HIGHUSER_MOVABLE to help
  callers to get ZONE_MOVABLE. Try to create __GFP_ZONE_MASK to mask
  lowest 3 bits of GFP bitmasks.

* Modify some callers' gfp flag to update usage of address zone
  modifiers.

* Modify inline function gfp_zone to get better performance according
  to Matthew's suggestion.

[1]: https://marc.info/?l=linux-mm=152596791931266=2

---

Huaisheng Ye (9):
  include/linux/gfp.h: get rid of GFP_ZONE_TABLE/BAD
  include/linux/dma-mapping: update usage of zone modifiers
  drivers/xen/swiotlb-xen: update usage of zone modifiers
  fs/btrfs/extent_io: update usage of zone modifiers
  drivers/block/zram/zram_drv: update usage of zone modifiers
  mm/vmpressure: update usage of zone modifiers
  mm/zsmalloc: update usage of zone modifiers
  include/linux/highmem.h: update usage of movableflags
  arch/x86/include/asm/page.h: update usage of movableflags

 arch/x86/include/asm/page.h   |   3 +-
 drivers/block/zram/zram_drv.c |   6 +--
 drivers/xen/swiotlb-xen.c |   2 +-
 fs/btrfs/extent_io.c  |   2 +-
 include/linux/dma-mapping.h   |   2 +-
 include/linux/gfp.h   | 107 

[Xen-devel] [RFC PATCH v3 4/9] fs/btrfs/extent_io: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MASK to replace (__GFP_DMA32 | __GFP_HIGHMEM).

In function alloc_extent_state, it is obvious that __GFP_DMA is not
the expecting zone type.

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 should not be operated with
each others by OR.

Use GFP_NORMAL() to clear bottom 3 bits of GFP bitmaks.

Signed-off-by: Huaisheng Ye 
Cc: Chris Mason 
Cc: Josef Bacik 
Cc: David Sterba 
Cc: Christoph Hellwig 
---
 fs/btrfs/extent_io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index e99b329..f41fc61 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -220,7 +220,7 @@ static struct extent_state *alloc_extent_state(gfp_t mask)
 * The given mask might be not appropriate for the slab allocator,
 * drop the unsupported bits
 */
-   mask &= ~(__GFP_DMA32|__GFP_HIGHMEM);
+   mask = GFP_NORMAL(mask);
state = kmem_cache_alloc(extent_state_cache, mask);
if (!state)
return state;
-- 
1.8.3.1



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH v3 5/9] drivers/block/zram/zram_drv: update usage of zone modifiers

[Huaisheng Ye]

From: Huaisheng Ye 

Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).

___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.

__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE flag.

With GFP_ZONE_TABLE, __GFP_HIGHMEM ORing __GFP_MOVABLE means gfp_zone
should return ZONE_MOVABLE. In order to keep that compatible with
GFP_ZONE_TABLE, replace (__GFP_HIGHMEM | __GFP_MOVABLE) with
__GFP_ZONE_MOVABLE.

Signed-off-by: Huaisheng Ye 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Sergey Senozhatsky 
Cc: Christoph Hellwig 
---
 drivers/block/zram/zram_drv.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 0f3fadd..1bb5ca8 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1004,14 +1004,12 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec,
handle = zs_malloc(zram->mem_pool, comp_len,
__GFP_KSWAPD_RECLAIM |
__GFP_NOWARN |
-   __GFP_HIGHMEM |
-   __GFP_MOVABLE);
+   __GFP_ZONE_MOVABLE);
if (!handle) {
zcomp_stream_put(zram->comp);
atomic64_inc(>stats.writestall);
handle = zs_malloc(zram->mem_pool, comp_len,
-   GFP_NOIO | __GFP_HIGHMEM |
-   __GFP_MOVABLE);
+   GFP_NOIO | __GFP_ZONE_MOVABLE);
if (handle)
goto compress_again;
return -ENOMEM;
-- 
1.8.3.1



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/9] x86/vmx: Internal cleanup for MSR load/save infrastructure

[Roger Pau Monné]

On Tue, May 22, 2018 at 12:20:39PM +0100, Andrew Cooper wrote:
>  * Use an arch_vmx_struct local variable to reduce later code volume.
>  * Use start/total instead of msr_area/msr_count.  This is in preparation for
>more finegrained handling with later changes.
>  * Use ent/end pointers (again for preparation), and to make the vmx_add_msr()
>logic easier to follow.
>  * Make the memory allocation block of vmx_add_msr() unlikely, and calculate
>virt_to_maddr() just once.
> 
> No practical change to functionality.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> ---
>  xen/arch/x86/hvm/vmx/vmcs.c | 74 
> -
>  1 file changed, 40 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index a5dcf5c..f557857 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1292,48 +1292,50 @@ static int vmx_msr_entry_key_cmp(const void *key, 
> const void *elt)
>  struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum vmx_msr_list_type type)
>  {
>  struct vcpu *curr = current;
> -unsigned int msr_count;
> -struct vmx_msr_entry *msr_area = NULL;
> +struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;

curr is used here only, so you can use current and get rid of the curr
local variable?

> +struct vmx_msr_entry *start = NULL;
> +unsigned int total;
>  
>  switch ( type )
>  {
>  case VMX_MSR_HOST:
> -msr_count = curr->arch.hvm_vmx.host_msr_count;
> -msr_area = curr->arch.hvm_vmx.host_msr_area;
> +start= arch_vmx->host_msr_area;
> +total= arch_vmx->host_msr_count;
>  break;
>  
>  case VMX_MSR_GUEST:
> -msr_count = curr->arch.hvm_vmx.msr_count;
> -msr_area = curr->arch.hvm_vmx.msr_area;
> +start= arch_vmx->msr_area;
> +total= arch_vmx->msr_count;

Not that I think is wrong, but why are you adding the extra spaces
after the variable name? Those assignments will already be aligned
because start and total names have the same length.

>  break;
>  
>  default:
>  ASSERT_UNREACHABLE();
>  }
>  
> -if ( msr_area == NULL )
> +if ( !start )
>  return NULL;
>  
> -return bsearch(, msr_area, msr_count, sizeof(struct vmx_msr_entry),
> +return bsearch(, start, total, sizeof(struct vmx_msr_entry),
> vmx_msr_entry_key_cmp);
>  }
>  
>  int vmx_add_msr(uint32_t msr, enum vmx_msr_list_type type)
>  {
>  struct vcpu *curr = current;

curr seems to be used only once below in order to get hvm_vmx? In
which case it could be removed.

> -unsigned int idx, *msr_count;
> -struct vmx_msr_entry **msr_area, *msr_area_elem;
> +struct arch_vmx_struct *arch_vmx = >arch.hvm_vmx;
> +struct vmx_msr_entry **ptr, *start = NULL, *ent, *end;

Do you really need to initialize start here? It seems like it's
unconditionally set to *ptr before any usage.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [OSSTEST PATCH v2 09/23] mg-anoint: Make readonly operations "work" in standalone mode

[Ian Jackson]

This makes `mg-anoint' in standalone mode a view onto an empty set of
anointments.  So now it becomes ok to call mg-anoint in make-*-flight.

Signed-off-by: Ian Jackson 
CC: Roger Pau Monné 
---
 Osstest/JobDB/Executive.pm  |  2 ++
 Osstest/JobDB/Standalone.pm |  2 ++
 mg-anoint   | 20 +++-
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index a7a6696..fe8e7f6 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -409,4 +409,6 @@ sub jobdb_db_glob ($$) { #method
 return "LIKE E'$str'";
 }
 
+sub can_anoint ($) { return 1; }
+
 1;
diff --git a/Osstest/JobDB/Standalone.pm b/Osstest/JobDB/Standalone.pm
index d9a90fc..4f320cc 100644
--- a/Osstest/JobDB/Standalone.pm
+++ b/Osstest/JobDB/Standalone.pm
@@ -133,4 +133,6 @@ sub jobdb_db_glob ($) { #method
 return "GLOB '$str'";
 }
 
+sub can_anoint ($) { return 0; }
+
 1;
diff --git a/mg-anoint b/mg-anoint
index b007ab4..522cbdd 100755
--- a/mg-anoint
+++ b/mg-anoint
@@ -66,7 +66,6 @@ use DBI;
 BEGIN { unshift @INC, qw(.); }
 use Osstest;
 use Osstest::TestSupport;
-use Osstest::Executive;
 use IO::Handle;
 use Text::Glob qw(glob_to_regex);
 
@@ -93,6 +92,15 @@ END
 our $task_q;
 our $mostrecent_q;
 
+sub empty_unless_can_anoint () {
+return if $mjobdb->can_anoint();
+exit 0;
+}
+sub fail_unless_can_anoint () {
+return if $mjobdb->can_anoint();
+die "anointments not supported in this mode ($c{JobDB})\n"
+}
+
 sub prep_queries {
 $task_q = $dbh_tests->prepare(<prepare(<prepare(<prepare(<prepare(<prepare(<

[Xen-devel] [OSSTEST PATCH v2 11/23] mfi-common: set_freebsd_runvars: Never set freebsd_distpath to `/amd64' etc.

[Ian Jackson]

Logically, the final branch of the if should be qualified with a check
for the emptiness of FreeBSDDist.  This is awkward in the current
structure, since we really want to do the distpath lookup only if
needed.  (This is not very important right now, but we are about to
add another case which will do a more-likely-to-bomb-out and
more-likely-to-block-on-the-db lookup.)  So refactor into `return'
style.  This lets us introduce local variables in each branch.

Now gate the final branch appropriately.  The overall result is that
if no useful FreeBSD build is found, we simply do not set the
freebsd_* runvars, rather than setting them to wrong values (eg,
`freebsd_distpath=/i386'.

Signed-off-by: Ian Jackson 
CC: Roger Pau Monné 
---
 mfi-common | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/mfi-common b/mfi-common
index cef28ad..17b1b50 100644
--- a/mfi-common
+++ b/mfi-common
@@ -133,14 +133,19 @@ set_freebsd_runvars () {
 local envvar="FREEBSD_${arch^^}_BUILDJOB"
 if [ -n "${!envvar}" ]; then
 freebsd_runvars="freebsdbuildjob=${!envvar}"
-elif [ -n "$FREEBSD_DIST" ] && [ -n "$FREEBSD_VERSION" ]; then
+return
+fi
+if [ -n "$FREEBSD_DIST" ] && [ -n "$FREEBSD_VERSION" ]; then
 freebsd_runvars="freebsd_distpath=$FREEBSD_DIST/$arch \
  freebsd_version=$FREEBSD_VERSION"
-else
-local distpath=`getconfig "FreeBSDDist"`
+return
+fi
+local distpath=`getconfig "FreeBSDDist"`
+if [ -n "$distpath" ]; then
 local version=`getconfig "FreeBSDVersion"`
 freebsd_runvars="freebsd_distpath=$distpath/$arch \
  freebsd_version=$version"
+return
 fi
 }
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [OSSTEST PATCH v2 21/23] 20_linux_xen: Use multiboot2 when Xen supports it

[Ian Jackson]

This is necessary for UEFI.  The patch is similar in spirit to the
upstream commit
  
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=b4d709b6ee789cdaf3fa7a80fd90c721a16f48c2

A backport of that commit to Debian buster was requested in
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898947
so hopefully this will not be necessary after stretch.

Signed-off-by: Ian Jackson 
---
 overlay-jessie/etc/grub.d/20_linux_xen  | 14 ++
 overlay-stretch/etc/grub.d/20_linux_xen | 14 ++
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/overlay-jessie/etc/grub.d/20_linux_xen 
b/overlay-jessie/etc/grub.d/20_linux_xen
index aaead1b..885f204 100755
--- a/overlay-jessie/etc/grub.d/20_linux_xen
+++ b/overlay-jessie/etc/grub.d/20_linux_xen
@@ -118,24 +118,30 @@ linux_entry ()
   printf '%s\n' "${prepare_boot_cache}"
   xmessage="$(gettext_printf "Loading Xen %s ..." ${xen_version})"
   lmessage="$(gettext_printf "Loading Linux %s ..." ${version})"
+  xen_loader=multiboot
+  xen_module=module
+  if grub-file --is-x86-multiboot2 $current_xen; then
+xen_loader=multiboot2
+xen_module=module2
+  fi
   cat << EOF
echo'$xmessage'
-   multiboot   ${rel_xen_dirname}/${xen_basename} placeholder 
${xen_args}
+   $xen_loader ${rel_xen_dirname}/${xen_basename} placeholder 
${xen_args}
echo'$lmessage'
-   module  ${rel_dirname}/${basename} placeholder 
root=${linux_root_device_thisversion} ro ${args}
+   $xen_module ${rel_dirname}/${basename} placeholder 
root=${linux_root_device_thisversion} ro ${args}
 EOF
   if test -n "${initrd}" ; then
 message="$(gettext_printf "Loading initial ramdisk ...")"
 cat << EOF
echo'$message'
-   module  ${rel_dirname}/${initrd}
+   $xen_module ${rel_dirname}/${initrd}
 EOF
   fi
   if test -n "${xenpolicy}" ; then
 message="$(gettext_printf "Loading XSM policy ...")"
 cat << EOF
echo'$message'
-   module  ${rel_dirname}/${xenpolicy}
+   $xen_module ${rel_dirname}/${xenpolicy}
 EOF
   fi
   cat << EOF
diff --git a/overlay-stretch/etc/grub.d/20_linux_xen 
b/overlay-stretch/etc/grub.d/20_linux_xen
index aaead1b..885f204 100755
--- a/overlay-stretch/etc/grub.d/20_linux_xen
+++ b/overlay-stretch/etc/grub.d/20_linux_xen
@@ -118,24 +118,30 @@ linux_entry ()
   printf '%s\n' "${prepare_boot_cache}"
   xmessage="$(gettext_printf "Loading Xen %s ..." ${xen_version})"
   lmessage="$(gettext_printf "Loading Linux %s ..." ${version})"
+  xen_loader=multiboot
+  xen_module=module
+  if grub-file --is-x86-multiboot2 $current_xen; then
+xen_loader=multiboot2
+xen_module=module2
+  fi
   cat << EOF
echo'$xmessage'
-   multiboot   ${rel_xen_dirname}/${xen_basename} placeholder 
${xen_args}
+   $xen_loader ${rel_xen_dirname}/${xen_basename} placeholder 
${xen_args}
echo'$lmessage'
-   module  ${rel_dirname}/${basename} placeholder 
root=${linux_root_device_thisversion} ro ${args}
+   $xen_module ${rel_dirname}/${basename} placeholder 
root=${linux_root_device_thisversion} ro ${args}
 EOF
   if test -n "${initrd}" ; then
 message="$(gettext_printf "Loading initial ramdisk ...")"
 cat << EOF
echo'$message'
-   module  ${rel_dirname}/${initrd}
+   $xen_module ${rel_dirname}/${initrd}
 EOF
   fi
   if test -n "${xenpolicy}" ; then
 message="$(gettext_printf "Loading XSM policy ...")"
 cat << EOF
echo'$message'
-   module  ${rel_dirname}/${xenpolicy}
+   $xen_module ${rel_dirname}/${xenpolicy}
 EOF
   fi
   cat << EOF
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel