[Xen-devel] [qemu-mainline test] 118102: regressions - trouble: blocked/broken/fail/pass

flight 118102 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/118102/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken build-armhf-libvirt 5

Re: [Xen-devel] [PATCH v3] kexec-tools: Perform run-time linking of libxenctrl.so

On Fri, Jan 12, 2018 at 03:21:13PM -0600, Eric DeVolder wrote: > When kexec is utilized in a Xen environment, it has an explicit > run-time dependency on libxenctrl.so. This dependency occurs > during the configure stage and when building kexec-tools. > > When kexec is utilized in a non-Xen

Re: [Xen-devel] [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads

On 15/01/18 11:26, Jan Beulich wrote: On 12.01.18 at 19:01, wrote: >> --- a/xen/include/asm-x86/spec_ctrl.h >> +++ b/xen/include/asm-x86/spec_ctrl.h >> @@ -20,8 +20,29 @@ >> #ifndef __X86_SPEC_CTRL_H__ >> #define __X86_SPEC_CTRL_H__ >> >> +#include >> + >>

Re: [Xen-devel] [PATCH 2/5] xen/arm64: Add missing MIDR values for Cortex-A72, A73 and A75

On Tue, 16 Jan 2018, Julien Grall wrote: > Cortex-A72, A73 and A75 MIDR will be used to a follow-up for hardening > the branch predictor. > > This is part of XSA-254. > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- >

[Xen-devel] [xen-unstable-smoke test] 118110: regressions - FAIL

flight 118110 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118110/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118105 build-armhf

Re: [Xen-devel] [PATCH 3/5] xen/arm: cpuerrata: Add MIDR_ALL_VERSIONS

On Tue, 16 Jan 2018, Julien Grall wrote: > Introduce a new macro MIDR_ALL_VERSIONS to match all variant/revision of a > given CPU model. > > This is part of XSA-254. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- >

Re: [Xen-devel] [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU

On Tue, 16 Jan 2018, Julien Grall wrote: > Once Xen knows what features/workarounds present on the platform, it > might be necessary to configure each online CPU. > > Introduce a new callback "enable" that will be called on each online CPU to > configure the "capability". > > The code is based

Re: [Xen-devel] [PATCH v8 12/17] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

On 15/01/18 12:09, Jan Beulich wrote: On 12.01.18 at 19:01, wrote: >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -668,6 +668,7 @@ void __init noreturn __start_xen(unsigned long mbi_p) >> set_processor_id(0); >>

Re: [Xen-devel] [PATCH v3 2/2] docs: note default for timer_mode in xl.cfg man

On Mon, Jan 15, 2018 at 09:24:52PM -0600, Doug Goldstein wrote: > There was no default documented but inspecting > libxl__domain_build_info_setdefault() shows the default to be > LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS. > > Signed-off-by: Doug Goldstein > --- > CC: Wei Liu

Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL

>>> On 16.01.18 at 09:43, wrote: > flight 118078 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/118078/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

>>> On 15.01.18 at 19:12, wrote: > Luwei Kang (7): > x86: add a flag to enable Intel processor trace > x86: configure vmcs for Intel processor trace virtualization > x86: add intel proecessor trace support for cpuid > x86: add intel processor trace context > x86:

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

>>> On 15.01.18 at 19:26, wrote: > On 15/01/18 11:07, Jan Beulich wrote: >> --- a/docs/misc/xen-command-line.markdown >> +++ b/docs/misc/xen-command-line.markdown >> @@ -1849,6 +1849,15 @@ In the case that x2apic is in use, this >> clustered mode. The default, given

[Xen-devel] [qemu-mainline test] 118091: regressions - FAIL

flight 118091 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/118091/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 117930

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

On 01/16/2018 07:12 AM, Jan Beulich wrote: On 15.01.18 at 17:54, wrote: >> On Jan 12, 2018, at 05:19, Jan Beulich wrote: >>> >>> This is a very simplistic change limiting the amount of memory a running >>> 64-bit PV guest has mapped (and hence available

Re: [Xen-devel] [PATCH v2] -xen-attach is needed for pvh boot with qemu-xen

On Mon, Jan 15, 2018 at 09:23:20PM +, Michael Young wrote: > Currently the boot of a pvh guest using the qemu-xen device model fails > with the error > xen emulation not implemented (yet) > in the qemu-dm log file. This patch adds the missing -xen-attach > argument. > > V2: Use b_info->type

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

On 16/01/18 09:33, Jan Beulich wrote: On 15.01.18 at 19:23, wrote: >> On 15/01/18 11:06, Jan Beulich wrote: >>> This also wants Andrew's "[PATCH RFC 11/44] x86/pt-shadow: Always set >>> _PAGE_ACCESSED on L4e updates". >> I've cleaned this patch up and committed it

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote: > First of all we don't need it on AMD systems. Additionally allow its use > to be controlled by command line option. For best backportability, this > intentionally doesn't use alternative instruction patching to achieve >

Re: [Xen-devel] [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote: > > @@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, > uint64_t val) >  { > const struct vcpu *curr = current; > struct domain *d = v->domain; > +    const struct cpuid_policy *cp = d->arch.cpuid; > struct

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

>>> On 15.01.18 at 19:23, wrote: > On 15/01/18 11:06, Jan Beulich wrote: >> This also wants Andrew's "[PATCH RFC 11/44] x86/pt-shadow: Always set >> _PAGE_ACCESSED on L4e updates". > > I've cleaned this patch up and committed it in preparation. > >

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

On 01/03/2018 05:47 AM, Manish Jaggi wrote: Hi Sameer, Hi Manish, + +/* Xen: Type definitions for iommu_domain */ +#define IOMMU_DOMAIN_UNMANAGED 0 +#define IOMMU_DOMAIN_DMA 1 +#define IOMMU_DOMAIN_IDENTITY 2 + +/* Xen: Dummy iommu_domain */ +struct iommu_domain { +    /* Runtime SMMU

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein wrote: > On 1/12/18 8:20 AM, Wei Liu wrote: >> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote: >>> On Fri, Jan 12, Wei Liu wrote: >>> Vixen Comet Guest console

Re: [Xen-devel] [PATCH v3 2/2] x86: allow Meltdown band-aid to be disabled

On 16/01/18 15:22, Jan Beulich wrote: > First of all we don't need it on AMD systems. Additionally allow its use > to be controlled by command line option. For best backportability, this > intentionally doesn't use alternative instruction patching to achieve > the intended effect - while we likely

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On 1/12/18 8:20 AM, Wei Liu wrote: > On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote: >> On Fri, Jan 12, Wei Liu wrote: >> >>> Vixen Comet >>> Guest console Output onlyBi-directional >> >> With the proper patch

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Tue, Jan 16, 2018 at 10:42:17AM -0600, Doug Goldstein wrote: > On 1/12/18 8:20 AM, Wei Liu wrote: > > On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote: > >> On Fri, Jan 12, Wei Liu wrote: > >> > >>> Vixen Comet > >>> Guest console

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote: > On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote: > > Hi all, > > > > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the > > other is called Comet. The long term goal is to merge the two > >

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

On Tue, Jan 16, 2018 at 12:35 PM, Jan Beulich wrote: On 16.01.18 at 13:12, wrote: >> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote: >>> First of all we don't need it on AMD systems. Additionally allow its use >>> to be

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

Hi Julien, On 01/16/2018 02:11 AM, Julien Grall wrote: On 01/03/2018 05:34 AM, Manish Jaggi wrote: Hi Sameer, Hi Manish, +    unsigned int    type; + +    /* Dummy compatibility defines */ +    unsigned long pgsize_bitmap; +    struct iommu_domain_geometry geometry; + +   

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

On Tue, Jan 16, 2018 at 12:21 PM, Juergen Gross wrote: > On 16/01/18 13:12, George Dunlap wrote: >> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote: >>> First of all we don't need it on AMD systems. Additionally allow its use >>> to be controlled by

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

On 16/01/18 12:33, Jan Beulich wrote: >> >> On 15.01.18 at 19:23, wrote: can we collect these together into macros, rather than opencoding? We seem to have 3 distinct variations. >>> I had considered that (following the model you use in the SP2 >>>

[Xen-devel] [PATCH V6] pci: removed the is_express field since a uniform interface was inserted

according to Eduardo Habkost's commit fd3b02c889 all PCIEs now implement INTERFACE_PCIE_DEVICE so we don't need is_express field anymore. Devices that implements only INTERFACE_PCIE_DEVICE (is_express == 1) or devices that implements only INTERFACE_CONVENTIONAL_PCI_DEVICE (is_express == 0) where

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

Hi Manish, On 16/01/18 13:27, Manish Jaggi wrote: On 01/16/2018 06:44 PM, Julien Grall wrote: On 16/01/18 12:40, Manish Jaggi wrote: Hi Julien, Hi, On 01/16/2018 02:11 AM, Julien Grall wrote: On 01/03/2018 05:34 AM, Manish Jaggi wrote: Hi Sameer, Hi Manish, +    unsigned int   

Re: [Xen-devel] [Embedded-pv-devel] Xen on RCarH3 Starter Kit

Dear Ganesh, Could you please specify your exact target board? Is it salvator-x or starter kit premier (h3ulcb)? Actually Renesas BSP 2.19.0 is easily being built for salvator-x. In step 8 you should select an appropriate conf from `meta-rcar-gen3/docs/sample/conf/salvator-x/`. > But the Yocto

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

>>> On 16.01.18 at 14:20, wrote: > The isolation is definitely not complete. Amongst other things, remote > stacks are in view of an attacker, which is why my KAISER-prereq series > pushes for the fully isolated per-pcpu range. How are remote stacks visible? The local

Re: [Xen-devel] [PATCH v8 02/17] x86: Support indirect thunks from assembly code

>>> On 16.01.18 at 14:55, wrote: > On 15/01/18 10:28, Jan Beulich wrote: >>> ctxt->io_emul_stub[10] = 0xff; >>> ctxt->io_emul_stub[11] = 0xd1; >>> >>> +/* >>> + * 3 bytes of P6_NOPS. >>> + * TODO: untangle ideal_nops from init/livepatch Kconfig

[Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

This is a very simplistic change limiting the amount of memory a running 64-bit PV guest has mapped (and hence available for attacking): Only the mappings of stack, IDT, and TSS are being cloned from the direct map into per-CPU page tables. Guest controlled parts of the page tables are being

Re: [Xen-devel] [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use

On 16/01/18 14:25, Boris Ostrovsky wrote: > On 01/16/2018 09:13 AM, Andrew Cooper wrote: >> On 16/01/18 14:10, Boris Ostrovsky wrote: >>> On 01/12/2018 01:01 PM, Andrew Cooper wrote: +if ( boot_cpu_has(X86_FEATURE_IBRSB) ) +{ +/* + * Even if we've

[Xen-devel] [PATCH v3 2/2] x86: allow Meltdown band-aid to be disabled

First of all we don't need it on AMD systems. Additionally allow its use to be controlled by command line option. For best backportability, this intentionally doesn't use alternative instruction patching to achieve the intended effect - while we likely want it, this will be later follow-up.

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

Hi Jan, On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote: > This is a very simplistic change limiting the amount of memory a running > 64-bit PV guest has mapped (and hence available for attacking): Only the > mappings of stack, IDT, and TSS are being cloned from the direct map > into

[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254 version 8 Information leak via side effects of speculative execution UPDATES IN VERSION 8 PVH shim ("Comet")

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

On Tue, Jan 16, 2018 at 5:28 PM, Andy Smith wrote: > Hi Jan, > > On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote: >> This is a very simplistic change limiting the amount of memory a running >> 64-bit PV guest has mapped (and hence available for attacking): Only

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Tue, Jan 16, 2018 at 5:51 PM, George Dunlap wrote: > On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein wrote: >> On 1/12/18 8:20 AM, Wei Liu wrote: >>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote: On Fri, Jan 12, Wei Liu wrote:

[Xen-devel] [xen-unstable test] 118096: regressions - FAIL

flight 118096 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/118096/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail in 118078 REGR. vs. 118003 Tests which are

Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols

Hi Jan, On 12/01/18 13:13, Jan Beulich wrote: On 09.01.18 at 20:43, wrote: When I compiled the snippet on x86 and Arm, no relocation is available for the pointers to string in the array in the final binary. Yet they are available in the object. I can see them there

Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Paul Durrant > Sent: 16 January 2018 09:27 > To: 'Jan Beulich' > Cc: xen-devel ; osstest- > ad...@xenproject.org > Subject: Re:

Re: [Xen-devel] [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

On 16/01/18 11:10, David Woodhouse wrote: > On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote: >> @@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, >> uint64_t val) >>  { >> const struct vcpu *curr = current; >> struct domain *d = v->domain; >> +    const struct

Re: [Xen-devel] [RFC 00/11] acpi: arm: IORT Support for Xen

Hi Manish, On 02/01/18 09:27, manish.ja...@linaro.org wrote: From: Manish Jaggi This patch aims to add the support of IORT in Xen. Below is the list of major components which this patchset provides. a. Add support for parsing the IORT b. Provides API to populate/query

Re: [Xen-devel] [RFC 01/11] acpi: arm: Public API for populating and query based on requesterid

Hi Manish, On 02/01/18 09:27, manish.ja...@linaro.org wrote: From: Manish Jaggi Public API to populate and query map between requester id and The commit message should not be indented. streamId/DeviceID. IORT is parsed one time (outside this patch) and two

[Xen-devel] [PATCH 07/10] arm64: Add ICV_IAR1_EL1 handler

From: Manish Jaggi Add a handler for reading the guest's view of the ICC_IAR1_EL1 register. This involves finding the highest priority Group-1 interrupt, checking against both PMR and the active group priority, activating the interrupt and setting the group priority as

[Xen-devel] [PATCH 06/10] Expose gicv3_ich_read/write_lr

From: Manish Jaggi gicv3_ich_read/write_lr functions are static in gic-v3.c This patch creates wrapper functions which can be used from outside the file. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3.c| 10 ++

[Xen-devel] [RFC PATCH 02/10] arm64: Add hook to handle guest GICv3 sysreg accesses

From: Manish Jaggi In order to start handling guest access to GICv3 system registers, let's add a hook that will get called when we trap a system register access. This handling code is kept independent of other traps. Set CONFIG_VGIC_ERRATA to enable this code.

[Xen-devel] [RFC PATCH 00/10] arm64: Mediate access to GICv3 sysregs at EL2

From: Manish Jaggi This patchset is a Xen port of Marc's patchset. arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1] The current RFC patchset is a subset of [1], as it handleing only Group1 traps as a PoC. Most of the trap code is added in vsysreg.c. Trap handler

[Xen-devel] [PATCH 10/10] Enable Trapping of Group1 registers which is controlled by command line

From: Manish Jaggi In order to be able to trap Group-1 GICv3 system registers, we need to set ICH_HCR_EL2.TALL1 before entering the guest. This is controlled by the command line parameter group1_trap. Singed-off-by: Manish Jaggi ---

[Xen-devel] [PATCH 03/10] arm64: Add ICV_BPR1_EL1 handler

From: Manish Jaggi Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1 register, which is located in the ICH_VMCR_EL2.BPR1 field. Signed-off-by: Manish Jaggi --- xen/arch/arm/arm64/vsysreg.c| 71

[Xen-devel] [PATCH 08/10] Add ICV_EOIR1_EL1 handler

From: Manish Jaggi Add a handler for writing the guest's view of the ICC_EOIR1_EL1 register. This involves dropping the priority of the interrupt, and deactivating it if required. Signed-off-by: Manish Jaggi --- xen/arch/arm/arm64/vsysreg.c

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

On 16/01/18 15:21, Jan Beulich wrote: > --- a/xen/include/asm-x86/x86_64/page.h > +++ b/xen/include/asm-x86/x86_64/page.h > @@ -24,8 +24,8 @@ > /* These are architectural limits. Current CPUs support only 40-bit phys. */ > #define PADDR_BITS 52 > #define VADDR_BITS 48

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

Dear Rajesh, You can try to get an I2C bus controller in DomU in PIO mode following [1], keeping in mind [2]. If you want it DMA capable you need Renesas IPMMU support in XEN [3], [4] to be incorporated. [1] - https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt [2] -

[Xen-devel] [PATCH 05/10] arm64: Add accessors for the ICH_APxRn_EL2 registers

From: Manish Jaggi define accessors that take the register number as a parameter. Signed-off-by: Manish Jaggi --- xen/arch/arm/arm64/vsysreg.c | 92 1 file changed, 92 insertions(+) diff --git

[Xen-devel] [PATCH 09/10] arm64: Add a handler for ICV_HPPIR1_EL1

From: Manish Jaggi Add a handler for reading the guest's view of the ICV_HPPIR1_EL1 register. This is a simple parsing of the available LRs, extracting the highest available interrupt. Signed-off-by: Manish Jaggi ---

[Xen-devel] [xen-unstable-smoke test] 118121: regressions - FAIL

flight 118121 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118121/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118105 build-armhf

[Xen-devel] [xen-unstable-smoke test] 118113: regressions - FAIL

flight 118113 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118113/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118105 build-armhf

Re: [Xen-devel] [PATCH 5/5] xen/arm64: Implement branch predictor hardening for affected Cortex-A CPUs

On Tue, 16 Jan 2018, Julien Grall wrote: > Cortex-A57, A72, A73 and A75 are susceptible to branch predictor > aliasing and can theoritically be attacked by malicious code. > > This patch implements a PSCI-based mitigation for these CPUs when > available. The call into firmware will invalidate the

[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm

branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-arm64-xsm testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug

[Xen-devel] [xen-unstable-smoke test] 118127: regressions - FAIL

flight 118127 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118127/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118105 build-armhf

[Xen-devel] [xen-unstable-smoke test] 118133: regressions - FAIL

flight 118133 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118133/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118105 build-armhf

[Xen-devel] [seabios test] 118108: regressions - FAIL

flight 118108 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118108/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

[Xen-devel] [xen-unstable-smoke test] 118139: regressions - FAIL

flight 118139 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118139/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 118105 build-armhf

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

On 01/16/2018 07:10 PM, Julien Grall wrote: Hi Manish, On 16/01/18 13:27, Manish Jaggi wrote: On 01/16/2018 06:44 PM, Julien Grall wrote: On 16/01/18 12:40, Manish Jaggi wrote: Hi Julien, Hi, On 01/16/2018 02:11 AM, Julien Grall wrote: On 01/03/2018 05:34 AM, Manish Jaggi wrote:

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

On 01/16/2018 06:44 PM, Julien Grall wrote: On 16/01/18 12:40, Manish Jaggi wrote: Hi Julien, Hi, On 01/16/2018 02:11 AM, Julien Grall wrote: On 01/03/2018 05:34 AM, Manish Jaggi wrote: Hi Sameer, Hi Manish, +    unsigned int    type; + +    /* Dummy compatibility

Re: [Xen-devel] [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use

On 01/12/2018 01:01 PM, Andrew Cooper wrote: > > +if ( boot_cpu_has(X86_FEATURE_IBRSB) ) > +{ > +/* > + * Even if we've chosen to not have IBRS set in Xen context, we still > + * need the IBRS entry/exit logic to virtualise IBRS support for > + * guests. >

Re: [Xen-devel] [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use

On 01/16/2018 09:13 AM, Andrew Cooper wrote: > On 16/01/18 14:10, Boris Ostrovsky wrote: >> On 01/12/2018 01:01 PM, Andrew Cooper wrote: >>> >>> +if ( boot_cpu_has(X86_FEATURE_IBRSB) ) >>> +{ >>> +/* >>> + * Even if we've chosen to not have IBRS set in Xen context, we

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

>>> On 16.01.18 at 13:12, wrote: > On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich wrote: >> First of all we don't need it on AMD systems. Additionally allow its use >> to be controlled by command line option. For best backportability, this >> intentionally

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote: > Hi all, > > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the > other is called Comet. The long term goal is to merge the two implementations > to one. > > Here I list the differences between the two

[Xen-devel] Access I2C bus from guest/DomU on ARM board

Hi Xen community I have built and brought up Xen 4.8 on Renesas RCar H3. For a specific requirement, I need to use the I2C bus of the board from Domain U. Is there a way to use the I2C bus from the guest? I have looked into para-virtualization and passthrough [1][2] but there isn't enough

[Xen-devel] [PATCH 4/5] xen/arm64: Add skeleton to harden the branch predictor aliasing attacks

Aliasing attacked against CPU branch predictors can allow an attacker to redirect speculative control flow on some CPUs and potentially divulge information from one context to another. This patch adds initial skeleton code behind a new Kconfig option to enable implementation-specific mitigations

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

>>> On 16.01.18 at 12:51, wrote: > On 16/01/18 07:46, Jan Beulich wrote: > On 15.01.18 at 19:23, wrote: >>> Also, can we collect these together into macros, rather than >>> opencoding? We seem to have 3 distinct variations. >> I had

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

Hi Julien, On 01/16/2018 02:04 AM, Julien Grall wrote: On 01/03/2018 05:47 AM, Manish Jaggi wrote: Hi Sameer, Hi Manish, + +/* Xen: Type definitions for iommu_domain */ +#define IOMMU_DOMAIN_UNMANAGED 0 +#define IOMMU_DOMAIN_DMA 1 +#define IOMMU_DOMAIN_IDENTITY 2 + +/* Xen: Dummy

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote: > On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote: > > Hi all, > > > > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the > > other is called Comet. The long term goal is to merge the two > >

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

Hi, On 16/01/18 12:37, Manish Jaggi wrote: On 01/16/2018 02:04 AM, Julien Grall wrote: On 01/03/2018 05:47 AM, Manish Jaggi wrote: +int devm_request_threaded_irq(struct device *dev, unsigned int irq, irq_handler_t handler, +  irq_handler_t thread_fn, unsigned long irqflags, + 

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

On 16/01/18 08:12, Jan Beulich wrote: On 15.01.18 at 19:26, wrote: >> On 15/01/18 11:07, Jan Beulich wrote: >>> --- a/docs/misc/xen-command-line.markdown >>> +++ b/docs/misc/xen-command-line.markdown >>> @@ -1849,6 +1849,15 @@ In the case that x2apic is in use,

Re: [Xen-devel] [PATCH v8 02/17] x86: Support indirect thunks from assembly code

On 15/01/18 10:28, Jan Beulich wrote: >> ctxt->io_emul_stub[10] = 0xff; >> ctxt->io_emul_stub[11] = 0xd1; >> >> +/* >> + * 3 bytes of P6_NOPS. >> + * TODO: untangle ideal_nops from init/livepatch Kconfig options. >> + */ >> +memcpy(>io_emul_stub[12], "\x0f\x1f\x00",

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Tue, Jan 16, 2018 at 01:03:06PM +, Roger Pau Monné wrote: > On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote: > > On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote: > > > Hi all, > > > > > > Two solutions are proposed to mitigate Meltdown. One is called Vixen and > > > the >

[Xen-devel] [PATCH 0/5] xen/arm64: Branch predictor hardening (XSA-254 variant 2)

Hi all, This series provides a framework for mitigating branch predictor hardening on Arm64 on exception entry. It also implements a dummy PSCI "VERSION" call as the hook for affected Cortex-A CPUs. This will invalidate the predictor state with the latest Arm Trusted Firmware patches which will

[Xen-devel] [PATCH 5/5] xen/arm64: Implement branch predictor hardening for affected Cortex-A CPUs

Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing and can theoritically be attacked by malicious code. This patch implements a PSCI-based mitigation for these CPUs when available. The call into firmware will invalidate the branch predictor state, preventing any malicious

[Xen-devel] [PATCH 3/5] xen/arm: cpuerrata: Add MIDR_ALL_VERSIONS

Introduce a new macro MIDR_ALL_VERSIONS to match all variant/revision of a given CPU model. This is part of XSA-254. Signed-off-by: Julien Grall --- xen/arch/arm/cpuerrata.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/arm/cpuerrata.c

[Xen-devel] [PATCH 2/5] xen/arm64: Add missing MIDR values for Cortex-A72, A73 and A75

Cortex-A72, A73 and A75 MIDR will be used to a follow-up for hardening the branch predictor. This is part of XSA-254. Signed-off-by: Julien Grall --- xen/include/asm-arm/processor.h | 6 ++ 1 file changed, 6 insertions(+) diff --git

Re: [Xen-devel] [RFC 01/11] acpi: arm: Public API for populating and query based on requesterid

Hi Manish, I sent the previous e-mail too soon. On 02/01/18 09:27, manish.ja...@linaro.org wrote: From: Manish Jaggi Public API to populate and query map between requester id and streamId/DeviceID. IORT is parsed one time (outside this patch) and two lists are

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

On 16/01/18 17:28, Andy Smith wrote: > Hi Jan, > > On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote: >> This is a very simplistic change limiting the amount of memory a running >> 64-bit PV guest has mapped (and hence available for attacking): Only the >> mappings of stack, IDT, and TSS

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Tue, Jan 16, 2018 at 05:55:38PM +, Andrew Cooper wrote: > On 16/01/18 17:11, Jan Beulich wrote: > On 16.01.18 at 17:52, wrote: > >> I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a > >> forward port of 4.10.0-shim-comet branch to staging. >

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

On Tue, Jan 16, 2018 at 05:28:40PM +, Andy Smith wrote: > Hi Jan, > > On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote: > > This is a very simplistic change limiting the amount of memory a running > > 64-bit PV guest has mapped (and hence available for attacking): Only the > >

Re: [Xen-devel] [libvirt test] 118006: regressions - FAIL

Jim Fehlig writes ("Re: [Xen-devel] [libvirt test] 118006: regressions - FAIL"): > Should be fixed by > https://libvirt.org/git/?p=libvirt.git;a=commit;h=66aa7e02c69cd90995f29dbfaca6c659ffe11693 Thanks for letting us know. Ian. ___ Xen-devel mailing

[Xen-devel] [xen-unstable-smoke test] 118105: tolerable all pass - PUSHED

flight 118105 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118105/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [Xen-devel] [RFC 02/11] acpi: arm: API to query estimated size of hardware domain's IORT

Hi Manish, On 02/01/18 09:28, manish.ja...@linaro.org wrote: From: Manish Jaggi Code to query estimated IORT size for hardware domain. Please avoid indenting the commit message. IORT for hardware domain is generated using the requesterId and deviceId map.

Re: [Xen-devel] [PATCH 2/2] xen-netfront: Fix race between device setup and open

On 01/11/2018 04:36 AM, Ross Lagerwall wrote: > When a netfront device is set up it registers a netdev fairly early on, > before it has set up the queues and is actually usable. A userspace tool > like NetworkManager will immediately try to open it and access its state > as soon as it appears. The

Re: [Xen-devel] Rudolph: merging Vixen and Comet

On Tue, Jan 16, 2018 at 07:23:43PM +0100, Anthony Liguori wrote: > On Tue, Jan 16, 2018 at 5:51 PM, George Dunlap wrote: > > On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein wrote: > >> On 1/12/18 8:20 AM, Wei Liu wrote: > >>> On Fri, Jan 12, 2018 at