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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-devel] [v2 5/6] drivers/passthrough/arm: Refactor code for arm smmu drivers

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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) > @@

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

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.

Re: [Xen-devel] MSR_SPEC_CTRL intercept

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

Re: [Xen-devel] MSR_SPEC_CTRL intercept

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

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

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:

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

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

Re: [Xen-devel] MSR_SPEC_CTRL intercept

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

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

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

Re: [Xen-devel] MSR_SPEC_CTRL intercept

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 )    

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

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

Re: [Xen-devel] MSR_SPEC_CTRL intercept

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

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

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

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

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:

Re: [Xen-devel] MSR_SPEC_CTRL intercept

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,

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

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

Re: [Xen-devel] MSR_SPEC_CTRL intercept

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

[Xen-devel] MSR_SPEC_CTRL intercept

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

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

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 |

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 -

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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.   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >