[Xen-devel] [PATCH v2 0/2] xen/arm: GICv3: Only initialize ITS when LPIs are available

Hi all, This small patch series fix an issue I discovered when using the Foundation model and the DT provided by Linux upstream. Indeed the Device-Tree is exposing an ITS but LPIs are not available. Resulting to an early crash on Xen. Whilst this looks a DT issue, Linux is able to cope with it.

[Xen-devel] [PATCH v2 1/2] xen/arm: GICv3: Parse ITS information from the firmware tables later on

There are Device Tree (e.g for the Foundation Model) out that describes the ITS but LPIs is not supported by the platform. Booting with such DT will result to an early Data Abort. The same DT is booting fine with a baremetal Linux because ITS will be initialized only when LPIs is supported.

[Xen-devel] [PATCH v2 2/2] xen/arm: GICv3: Only initialize ITS when the distributor supports LPIs.

There are firmware tables out describing the ITS but does not support LPIs. This will result to a data abort when trying to initialize ITS. While this can be consider a bug in the Device-Tree, same configuration boots on Linux. So gate the ITS initialization with the support of LPIs in the

[Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

At the moment PSCI function dispatching is done in vsmc.c and the function implementation in vpsci.c. Some bits of the implementation is even done in vsmc.c (see PSCI_SYSTEM_RESET). This means that it is difficult to follow the implementation and also requires to export functions for each PSCI

[Xen-devel] [PATCH 0/3] xen/arm: SMCCC fixes and PSCI clean-up

Hi all, This small patch series contains SMCCC fixes (see #2) and PSCI clean-up. Cheers, Julien Grall (3): xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU xen/arm: vsmc: Don't implement function ID that doesn't exist xen/arm: vpsci: Move PSCI function dispatching from

Re: [Xen-devel] [PATCH] xen: Credit2: enable fully custom runqueue arrangement

On Wed, 2018-01-24 at 11:44 +, George Dunlap wrote: > On 09/13/2017 05:21 PM, Dario Faggioli wrote: > > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen- > > command-line.markdown > > index 9797c8d..dbf5d4c 100644 > > --- a/docs/misc/xen-command-line.markdown > > +++

[Xen-devel] [PATCH 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

The current implementation of SMCCC relies on the fact only function number (bits [15:0]) is enough to identify what to implement. However, PSCI call are only available in the range 0x8400-0x841F and 0xC400-0xC41F. Furthermore, not all SMC32 functions have equivalent in the SMC64.

[Xen-devel] [PATCH 1/3] xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU

The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and implemented as just returning PSCI_NOT_SUPPORTED (aka UNKNOWN_FUNCTION for SMCCC). The new SMCCC framework is able to deal with unimplemented function and return the proper error code. So remove the implementations for both function.

Re: [Xen-devel] [PATCH] x86: fix GET_STACK_END

From: Wei Liu [wei.l...@citrix.com] Sent: 24 January 2018 20:26 To: Xen-devel Cc: Wei Liu; Jan Beulich; Andrew Cooper Subject: [PATCH] x86: fix GET_STACK_END AIUI the purpose of having the .if directive is to make GET_STACK_END work with any general

[Xen-devel] [PATCH v3 2/8] ARM: VGIC: split gic.c to observe hardware/virtual GIC separation

Currently gic.c holds code to handle hardware IRQs as well as code to bridge VGIC requests to the GIC virtualization hardware. Despite being named gic.c, this file reaches into the VGIC and uses data structures describing virtual IRQs. To improve abstraction, move the VGIC functions into a

[Xen-devel] [PATCH v3 0/8] ARM: VGIC/GIC separation cleanups

Hi, minor updates to this series. Three patches have been merged already. Patch 1/8 (was v2 04/10) has been significantly reworked to address Stefano's comments, see the reply to his v2 comment. The rest has just been rebased and got tagged, if appropriate. The last patch is an improvement to the

[Xen-devel] [PATCH v3 7/8] ARM: VGIC: rework gicv[23]_update_lr to not use pending_irq

The functions to actually populate a list register were accessing the VGIC internal pending_irq struct, although they should be abstracting from that. Break the needed information down to remove the reference to pending_irq from gic-v[23].c. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v3 6/8] ARM: VGIC: factor out vgic_get_hw_irq_desc()

At the moment we happily access the VGIC internal struct pending_irq (which describes a virtual IRQ) in irq.c. Factor out the actually needed functionality to learn the associated hardware IRQ and move that into gic-vgic.c to improve abstraction. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v3 3/8] ARM: VGIC: split up gic_dump_info() to cover virtual part separately

Currently gic_dump_info() not only dumps the hardware state of the GIC, but also the VGIC internal virtual IRQ lists. Split the latter off and move it into gic-vgic.c to observe the abstraction. Signed-off-by: Andre Przywara Reviewed-by: Stefano Stabellini

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

flight 118310 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118310/ 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

[Xen-devel] [PATCH] x86/emul: Split exception handling out of invoke_stub()

For a release build, bloat-o-meter reports: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111) function old new delta x86_emulate 126458 121347 -5111 or in other words, a 4% redunction in code size from this

Re: [Xen-devel] [PATCH 1/2] xen/arm: GICv3: Parse ITS information from the firmware tables later on

Hi, On 22/01/18 18:22, Julien Grall wrote: There are Device Tree (e.g for the Foundation Model) out that describes the ITS but LPIs is not supported by the platform. Booting with such DT will result to an early Data Abort. The same DT is booting fine with a baremetal Linux because ITS will be

Re: [Xen-devel] [PATCH 3/6] xen/pvshim: identity pin shim vCPUs to pCPUs

On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne wrote: > Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU > hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent > vCPU migration and should improve performance. > > While there also use

[Xen-devel] [PATCH v3 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

At the moment we happily access VGIC internal data structures like the rank and struct pending_irq in gic.c, which should be VGIC agnostic. Factor out a new function vgic_connect_hw_irq(), which allows a virtual IRQ to be connected to a hardware IRQ (using the hw bit in the LR). This removes

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

Hi Oleksandr, Edgar, Thanks, you're right. On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote: On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote: Hi Mirela, Just some remarks regarding the scope of work: +In addition, the following have to be implemented: +* Suspend/resume

[Xen-devel] [PATCH] x86: fix GET_STACK_END

AIUI the purpose of having the .if directive is to make GET_STACK_END work with any general purpose registers. The code as-is would produce the wrong result for r8. Fix it. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper

Re: [Xen-devel] XSA-254 SP2 for ARM (was Re: [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU)

On Thu, 18 Jan 2018, Julien Grall wrote: > (+ Security team) > > Hi Stefano, > > On 17/01/18 21:47, Stefano Stabellini wrote: > > On Wed, 17 Jan 2018, Stefano Stabellini wrote: > > > On Wed, 17 Jan 2018, Lars Kurth wrote: > > > >Regarding README.source, this is covering file and contain

Re: [Xen-devel] [PATCH 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

On 24 January 2018 at 22:22, Konrad Rzeszutek Wilk wrote: > On Fri, Jan 19, 2018 at 01:41:01PM +, Julien Grall wrote: >> In order to avoid aliasing attackes agains the branch predictor, let's >> invalidate the BTB on guest exist. This is made complicated by the fact >>

[Xen-devel] GPU passthrough on ARM

Hi, Does anyone know if GPU passthrough is supported on ARM? (e.g. for a GPU integrated into an ARM SoC). I checked documentation and the code, but I couldn't tell for sure. If so, what are the hardware requirements for it? If not, is it feasible to do in the future? Thanks, Martin

Re: [Xen-devel] [PATCH 3/7] xen/arm32: entry: Add missing trap_reset entry

On Fri, 19 Jan 2018, Julien Grall wrote: > At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0, > r0). > > This is rather unintuitive and will result to execute the trap > undefined. Instead introduce trap helpers for reset and will generate an > error message in the unlikely

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

On 24/01/2018 22:31, Bitweasil . wrote: > I've recently discovered that if you attempt to use introspection to > capture CR3 changes with the new KPTI enabled kernels, the guest dies > shortly after the start of introspection with failed VM entry due to > invalid guest state. > > I believe the

Re: [Xen-devel] XSA-254 SP2 for ARM (was Re: [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU)

On Wed, 24 Jan 2018, Julien Grall wrote: > Hi Stefano, > > On 24 January 2018 at 22:14, Stefano Stabellini > wrote: > > On Thu, 18 Jan 2018, Julien Grall wrote: > >> (+ Security team) > >> > >> Hi Stefano, > >> > >> On 17/01/18 21:47, Stefano Stabellini wrote: > >> > On

Re: [Xen-devel] [PATCH 2/7] xen/arm32: Add missing MIDR values for Cortex-A17 and A12

On Fri, 19 Jan 2018, Julien Grall wrote: > Cortex-A17 and A12 MIDR will be used in a follow-up patch for hardening > the branch predictor. > > This is part of XSA-254. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- >

[Xen-devel] [linux-4.1 test] 118294: tolerable FAIL - PUSHED

flight 118294 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/118294/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 117197 test-amd64-i386-xl-qemut-win7-amd64 17

[Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

I've recently discovered that if you attempt to use introspection to capture CR3 changes with the new KPTI enabled kernels, the guest dies shortly after the start of introspection with failed VM entry due to invalid guest state. I believe the invalid state here is the high bit being set in CR3 -

Re: [Xen-devel] XSA-254 SP2 for ARM (was Re: [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU)

Hi Stefano, On 24 January 2018 at 22:14, Stefano Stabellini wrote: > On Thu, 18 Jan 2018, Julien Grall wrote: >> (+ Security team) >> >> Hi Stefano, >> >> On 17/01/18 21:47, Stefano Stabellini wrote: >> > On Wed, 17 Jan 2018, Stefano Stabellini wrote: >> > > On Wed, 17

Re: [Xen-devel] [PATCH 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

On Fri, Jan 19, 2018 at 01:41:01PM +, Julien Grall wrote: > In order to avoid aliasing attackes agains the branch predictor, let's > invalidate the BTB on guest exist. This is made complicated by the fact > that we cannot take a branch invalidating the BTB. > > This is based on the first

Re: [Xen-devel] [PATCH 1/7] xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros

On Fri, 19 Jan 2018, Julien Grall wrote: > The only difference between all the DEFINE_TRAP_ENTRY_* macros are the > interrupts (Asynchronous Abort, IRQ, FIQ) unmasked. > > Rather than duplicating the code, introduce __DEFINE_TRAP_ENTRY macro > that will take the list of interrupts to unmask. >

Re: [Xen-devel] [PATCH 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

On Fri, 19 Jan 2018, Julien Grall wrote: > 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 initiatial skeleton code behind a new Kconfig

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

On 01/25/2018 12:31 AM, Bitweasil . wrote: > I've recently discovered that if you attempt to use introspection to > capture CR3 changes with the new KPTI enabled kernels, the guest dies > shortly after the start of introspection with failed VM entry due to > invalid guest state. > > I believe the

[Xen-devel] [linux-linus test] 118298: regressions - trouble: broken/fail/pass

flight 118298 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/118298/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu broken test-armhf-armhf-xl-multivcpu 4

Re: [Xen-devel] [PATCH 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

On Fri, 19 Jan 2018, Julien Grall wrote: > In order to avoid aliasing attackes agains the branch predictor, let's > invalidate the BTB on guest exist. This is made complicated by the fact > that we cannot take a branch invalidating the BTB. > > This is based on the first version posrted by Marc

Re: [Xen-devel] [PATCH 6/7] xen/arm32: Invalidate icache on guest exist for Cortex-A15

On Fri, 19 Jan 2018, Julien Grall wrote: > In order to avoid aliasing attacks against the branch predictor on > Cortex A-15, let's invalidate the BTB on guest exit, which can only be > done by invalidating the icache (with ACTLR[0] being set). > > We use the same hack as for A12/A17 to perform

Re: [Xen-devel] [PATCH 7/7] xen/arm32: entry: Document the purpose of r11 in the traps handler

On Fri, 19 Jan 2018, Julien Grall wrote: > It took me a bit of time to understand why __DEFINE_TRAP_ENTRY is > storing the original stack pointer in r11. It is working in pair with > return_traps_entry where sp will be restored from r11. > > This is fine because per the AAPCS r11 must be

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

flight 118296 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/118296/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 118174

Re: [Xen-devel] [PATCH] xen/VT-d: Remove the use of __LINE__ from IOMMU_WAIT_OP()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, January 24, 2018 10:12 PM > > The use of __LINE__ in printk()'s is problematic for livepatching, as it tends > to cause unnecessary binary differences. > > Take this opportunity to provide some rather more useful

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On Wed, Jan 24, 2018 at 09:42:57AM -0500, Boris Ostrovsky wrote: > On 01/24/2018 09:25 AM, Juergen Gross wrote: > > On 24/01/18 15:10, Boris Ostrovsky wrote: > >> > >> I suspect we can do as little as removing "#ifdef CONFIG_KEXEC" around > >> acpi_rsdp in drivers/acpi/osl.c and then assigning it

Re: [Xen-devel] [PATCH] x86/mm: Add debug code to detect illegal page_lock and put_page_type ordering

On 01/24/2018 01:04 PM, Andrew Cooper wrote: > On 24/01/18 12:48, George Dunlap wrote: >> The fix for XSA-242 depends on the same cpu never calling >> _put_page_type() while holding a page_lock() for that page. By having >> no locking discipline between pages, the current code also assumes >>

[Xen-devel] [PATCH] xen/VT-d: Remove the use of __LINE__ from IOMMU_WAIT_OP()

The use of __LINE__ in printk()'s is problematic for livepatching, as it tends to cause unnecessary binary differences. Take this opportunity to provide some rather more useful information than just file/line/func in the form of the full register/stack trace leading to the problem (which I've

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

On Wed, 2018-01-24 at 13:49 +, Andrew Cooper wrote: > On 24/01/18 13:34, Woodhouse, David wrote: > > I am loath to suggest *more* tweakables, but given the IBPB cost is > > there any merit in having a mode which does it only if the *domain* is > > different, regardless of vcpu_id? > > This

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On 01/24/2018 09:25 AM, Juergen Gross wrote: > On 24/01/18 15:10, Boris Ostrovsky wrote: >> >> I suspect we can do as little as removing "#ifdef CONFIG_KEXEC" around >> acpi_rsdp in drivers/acpi/osl.c and then assigning it the value in >> pvh_start_info.rsdp_paddr. (I haven't tried it) > That was

[Xen-devel] [PATCH v2] x86/mm: Add debug code to detect illegal page_lock and put_page_type ordering

The fix for XSA-242 depends on the same cpu never calling _put_page_type() while holding a page_lock() for that page; doing so may cause a deadlock under the right conditions. Furthermore, even before that, there was never any discipline for the order in which page locks are grabbed; if there are

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky wrote: > On 01/24/2018 07:06 AM, Juergen Gross wrote: >> On 24/01/18 11:54, Roger Pau Monné wrote: >>> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote: On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky

Re: [Xen-devel] [PATCH v3 6/7] xsm: add bodge when compiling with llvm coverage support

On 01/24/2018 05:01 AM, Roger Pau Monne wrote: llvm coverage support seems to disable some of the optimizations needed in order to compile xsm, and the end result is that references to __xsm_action_mismatch_detected are left in the object files. Since coverage support cannot be used in

[Xen-devel] [PATCH] intel_iommu: allow updating FEADDR and FEUADDR with one 64bit write

Allow updating those two adjacent 32bit fields with one 64bit write. This fixes qemu crash when booting Xen inside. See discussion on Xen side of the thing here: http://xen.markmail.org/message/6mrmemrnmhxvaxba Signed-off-by: Marek Marczykowski-Górecki ---

[Xen-devel] [PATCH 2/7] ARM: vGICv3: drop GUEST_GICV3_RDIST_REGIONS symbol

Architecturally there is only one GICv3 redistributor region. Drop the symbol which suggested that was a delibarate choice for Xen guests, instead hard code the "1" in the appropriate places, along with a comment to explain the reasons. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH 4/7] ARM: GICv3: use hardware GICv3 redistributor regions for Dom0

The code to generate the DT node or MADT table for Dom0 reaches into the domain's VGIC structure to learn the number of redistributor regions and their base addresses. Since those values are copied from the hardware, we can as well use those hardware values directly when setting up the hardware

[Xen-devel] [PATCH 3/7] ARM: GICv3: emit optional DT property only when necessary

The ARM GICv3 DT property "#redistributor-regions" is optional and only useful if it has any other values than the architected "1". Keep our generated DT node clean by emitting this property only if we actually need more than one region. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH 1/7] tools: ARM: vGICv3: avoid inserting optional DT properties

When creating a GICv3 devicetree node, we currently insert the redistributor-stride and #redistributor-regions properties, with fixed values which are actually the architected ones. But those properties are optional and only needed to cover for broken platforms, where the values differ from the

[Xen-devel] [PATCH 6/7] ARM: vGICv3: always use architected redist stride

The redistributor-stride property in a GICv3 DT node is only there to cover broken platforms where this value deviates from the architected one. Since we emulate the GICv3 distributor even for Dom0, we don't need to copy the broken behaviour. All the special handling for Dom0s using GICv3 is just

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

flight 118305 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118305/ 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] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On 24/01/18 16:07, George Dunlap wrote: > On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky > wrote: >> On 01/24/2018 07:06 AM, Juergen Gross wrote: >>> On 24/01/18 11:54, Roger Pau Monné wrote: On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote: >

Re: [Xen-devel] [PATCH 3/7] ARM: GICv3: emit optional DT property only when necessary

Hi Andre, On 24/01/18 14:35, Andre Przywara wrote: The ARM GICv3 DT property "#redistributor-regions" is optional and only useful if it has any other values than the architected "1". Keep our generated DT node clean by emitting this property only if we actually need more than one region. I

Re: [Xen-devel] [PATCH RFC] xen: Improvements to domain_crash_sync()

On 24/01/18 16:15, Andrew Cooper wrote: > On 24/01/18 16:11, Jan Beulich wrote: > On 24.01.18 at 16:49, wrote: >>> The use of __LINE__ in a printk() is problematic for livepatching, as it >>> causes unnecessary binary differences. >>> >>> Furthermore, diagnostic

Re: [Xen-devel] [PATCH 1/7] tools: ARM: vGICv3: avoid inserting optional DT properties

Hi Andre, On 24/01/18 16:35, Andre Przywara wrote: On 24/01/18 16:08, Julien Grall wrote: (+ Tools maintainers) Hi Andre, On 24/01/18 14:35, Andre Przywara wrote: When creating a GICv3 devicetree node, we currently insert the redistributor-stride and #redistributor-regions properties, with

Re: [Xen-devel] [PATCH 4/7] ARM: GICv3: use hardware GICv3 redistributor regions for Dom0

Hi Andre, On 24/01/18 14:35, Andre Przywara wrote: The code to generate the DT node or MADT table for Dom0 reaches into the domain's VGIC structure to learn the number of redistributor regions and their base addresses. Since those values are copied from the hardware, we can as well use those

Re: [Xen-devel] [PATCH RFC] xen: Improvements to domain_crash_sync()

On 24/01/18 16:46, Jan Beulich wrote: On 24.01.18 at 17:31, wrote: >> On 24/01/18 16:15, Andrew Cooper wrote: >>> On 24/01/18 16:11, Jan Beulich wrote: >>> On 24.01.18 at 16:49, wrote: > --- a/xen/include/xen/sched.h > +++

Re: [Xen-devel] [PATCH 2/2] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

On Wed, Jan 24, 2018 at 09:23:37AM -0700, Jan Beulich wrote: > >>> On 24.01.18 at 16:48, wrote: > > When indirect_thunk_asm.h is instantiated directly into assembly files > > CONFIG_INDIRECT_THUNK might not be defined, and thus using .if against > > it is wrong. > > > > Add

Re: [Xen-devel] [PATCH 2/7] ARM: vGICv3: drop GUEST_GICV3_RDIST_REGIONS symbol

Hi, On 24/01/18 16:13, Julien Grall wrote: > Hi Andre, > > On 24/01/18 14:35, Andre Przywara wrote: >> Architecturally there is only one GICv3 redistributor region. >> Drop the symbol which suggested that was a delibarate choice for Xen >> guests, instead hard code the "1" in the appropriate

[Xen-devel] [PATCH v1 1/4] libxl: use libxl__device_kind to get device XS entry

From: Oleksandr Grytsov On adding to XS name of device is taken from libxl__device_kind enum. On getting device from XS the name is hardcoded. It leads to potential mistmatch errors. The patch is using libxl__device_kind everywere to have one source of device name.

[Xen-devel] [PATCH v1 3/4] libxl: move libxl__device_from_ to LIBXL_DEFINE_DEVICE_FROM_TYPE

From: Oleksandr Grytsov LIBXL_DEFINE_DEVICE_FROM_TYPE uses libxl__..._devtype.type to be assigned as device and backend type. Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu --- tools/libxl/libxl_9pfs.c | 19

[Xen-devel] [PATCH v1 4/4] libxl: move ibxl_devid_to_device_... to LIBXL_DEFINE_DEVID_TO_DEVICE

From: Oleksandr Grytsov Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu --- tools/libxl/libxl_internal.h | 38 ++ tools/libxl/libxl_nic.c | 22 +-

[Xen-devel] [PATCH v1 0/4] libxl: use libxl__device_kind string to access device

From: Oleksandr Grytsov Changes since initial version: * add libxl__domain_device_..._path functions to get backend, frontend, libxl device path's from device type, domain id and device id * rebase Oleksandr Grytsov (4): libxl: use libxl__device_kind to get

Re: [Xen-devel] [PATCH 1/7] tools: ARM: vGICv3: avoid inserting optional DT properties

Hi, On 24/01/18 16:08, Julien Grall wrote: > (+ Tools maintainers) > > Hi Andre, > > On 24/01/18 14:35, Andre Przywara wrote: >> When creating a GICv3 devicetree node, we currently insert the >> redistributor-stride and #redistributor-regions properties, with fixed >> values which are actually

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On 01/24/2018 11:15 AM, Juergen Gross wrote: > On 24/01/18 17:10, Boris Ostrovsky wrote: > >> So what is the problem here? - current Linux can't be booted as PVH guest with xen-unstable due to a bug in Linux, patches for Linux are being worked on >> I would prefer for patches

Re: [Xen-devel] [PATCH 1/2] x86/clang: fix build with indirect thunks

>>> On 24.01.18 at 16:48, wrote: > The build with clang is currently broken because clang requires asm > macros to be declared inside the same inline asm declaration where > they are used. I don't understand this: What if I have two asm()-s needing it? Does this need to be

Re: [Xen-devel] [PATCH RFC] xen: Improvements to domain_crash_sync()

>>> On 24.01.18 at 17:15, wrote: > On 24/01/18 16:11, Jan Beulich wrote: > On 24.01.18 at 16:49, wrote: >>> The use of __LINE__ in a printk() is problematic for livepatching, as it >>> causes unnecessary binary differences. >>> >>>

Re: [Xen-devel] [PATCH RFC] xen: Improvements to domain_crash_sync()

>>> On 24.01.18 at 17:31, wrote: > On 24/01/18 16:15, Andrew Cooper wrote: >> On 24/01/18 16:11, Jan Beulich wrote: >> On 24.01.18 at 16:49, wrote: --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -627,11

Re: [Xen-devel] [PATCH 1/2] x86/clang: fix build with indirect thunks

On Wed, Jan 24, 2018 at 09:40:40AM -0700, Jan Beulich wrote: > >>> On 24.01.18 at 16:48, wrote: > > The build with clang is currently broken because clang requires asm > > macros to be declared inside the same inline asm declaration where > > they are used. > > I don't

[Xen-devel] [PATCH v1 2/4] libxl: use libxl__device_kind in LIBXL_DEFINE_UPDATE_DEVID

From: Oleksandr Grytsov Use libxl__..._devtype.type to update device id. Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu --- tools/libxl/libxl_9pfs.c | 2 +- tools/libxl/libxl_console.c | 4 ++--

Re: [Xen-devel] [PATCH 7/7] ARM: vGICv3: remove rdist_stride from VGIC structure

Hi Andre, On 24/01/18 14:35, Andre Przywara wrote: The last patch removed the usage of the hardware's redistributor-stride value from our (Dom0) GICv3 emulation. This means we no longer need to store this value in the VGIC data structure. Remove that variable and every code snippet that handled

Re: [Xen-devel] [PATCH 6/7] ARM: vGICv3: always use architected redist stride

Hi Andre, On 24/01/18 14:35, Andre Przywara wrote: The redistributor-stride property in a GICv3 DT node is only there to cover broken platforms where this value deviates from the architected one. Since we emulate the GICv3 distributor even for Dom0, we don't need to copy the broken behaviour.

Re: [Xen-devel] [PATCH v1 1/4] libxl: use libxl__device_kind to get device XS entry

On Wed, Jan 24, 2018 at 07:19:56PM +0200, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > On adding to XS name of device is taken from > libxl__device_kind enum. On getting device from XS > the name is hardcoded. It leads to potential > mistmatch errors. The

Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:

On Wed, 24 Jan 2018, Andrew Cooper wrote: > On 24/01/18 00:47, Stefano Stabellini wrote: > > On Tue, 23 Jan 2018, Jan Beulich wrote: > > On 23.01.18 at 01:41, wrote: > >>> On 23/01/2018 00:38, Stefano Stabellini wrote: > On Tue, 23 Jan 2018, Andrew Cooper

[Xen-devel] [linux-4.9 test] 118291: tolerable FAIL - PUSHED

flight 118291 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/118291/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118204 test-amd64-amd64-xl-qemuu-win7-amd64

Re: [Xen-devel] [PATCH v2 04/10] ARM: VGIC: streamline gic_restore_pending_irqs()

Hi, sorry for the delay on this, I just found this in preparation for a repost. On 08/12/17 21:40, Stefano Stabellini wrote: > On Thu, 7 Dec 2017, Andre Przywara wrote: >> In gic_restore_pending_irqs() we push our pending virtual IRQs into the >> list registers. This function is called once from

Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:

On Wed, 24 Jan 2018, Roger Pau Monné wrote: > On Tue, Jan 23, 2018 at 04:47:51PM -0800, Stefano Stabellini wrote: > > On Tue, 23 Jan 2018, Jan Beulich wrote: > > > >>> On 23.01.18 at 01:41, wrote: > > > > On 23/01/2018 00:38, Stefano Stabellini wrote: > > > >> On Tue,

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

Hi Julien, Stefano, Thank you very much for the feedback! On 01/11/2018 03:00 PM, Julien Grall wrote: Hi Mirela, Thank you for the sending the design document. The general design looks good to me. I have some comments below, but they are more related to the implementation of CPU on/off in

Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:

On Tue, Jan 23, 2018 at 04:47:51PM -0800, Stefano Stabellini wrote: > On Tue, 23 Jan 2018, Jan Beulich wrote: > > >>> On 23.01.18 at 01:41, wrote: > > > On 23/01/2018 00:38, Stefano Stabellini wrote: > > >> On Tue, 23 Jan 2018, Andrew Cooper wrote: > > >>> On 22/01/2018

Re: [Xen-devel] [PATCH v4 2/6] x86/hvm: Provide XEN_DMOP_relocate_memory

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 24 January 2018 08:10 > To: Ross Lagerwall > Cc: Andrew Cooper ; Paul Durrant > ; Wei Liu ; George Dunlap >

Re: [Xen-devel] [Minios-devel] Preparing for GSoC and Outreachy : getting Outreach Program Projects into good shape

Hi all, since we are participating the first time to GSoC, we are happy to receive any feedback from you regarding our proposed Unikraft projects! https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Unikraft Thanks, Simon On 23.01.2018 10:16, Lars Kurth wrote: Hi all, just a quick

Re: [Xen-devel] [Minios-devel] Preparing for GSoC and Outreachy : getting Outreach Program Projects into good shape

Hi all, since we are participating the first time to GSoC, we are happy to receive any feedback from you regarding our proposed Unikraft projects! https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Unikraft Thanks, Simon On 23.01.2018 10:16, Lars Kurth wrote: Hi all, just a quick

[Xen-devel] [PATCH v3 1/7] gcov: rename sysctl and functions

Change gcov to cov (for internal interfaces) or coverage (for the public ones). Signed-off-by: Roger Pau Monné Reviewed-by: Konrad Rzeszutek Wilk Acked-by: Ian Jackson --- Cc: Ian Jackson Cc:

[Xen-devel] [xen-4.8-testing test] 118285: regressions - FAIL

flight 118285 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118285/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win10-i386 6 xen-install fail REGR. vs. 118170

[Xen-devel] [PATCH v3 4/7] kconfig/gcov: rename to coverage

So it can be used by both gcc and clang. Just add the Kconfig option and modify the makefiles so the llvm coverage specific code can be added in a follow up patch. Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap

[Xen-devel] [PATCH v3 3/7] coverage: introduce generic file

It will contain the generic implementation of sysctl_cov_op, which will be shared between all the coverage implementations. Signed-off-by: Roger Pau Monné Reviewed-by: Konrad Rzeszutek Wilk --- Cc: Andrew Cooper Cc:

[Xen-devel] [PATCH v3 0/7] LLVM coverage support for Xen

Hello, The following patch series enables LLVM coverage support for the Xen hypervisor. A sample coverage report obtained after booting a PVHv2 Dom0 can be found at: http://xenbits.xen.org/people/royger/xen_profile/ I know the time is not the most appropriate given all the security work going

[Xen-devel] [PATCH v3 6/7] xsm: add bodge when compiling with llvm coverage support

llvm coverage support seems to disable some of the optimizations needed in order to compile xsm, and the end result is that references to __xsm_action_mismatch_detected are left in the object files. Since coverage support cannot be used in production, introduce __xsm_action_mismatch_detected for

[Xen-devel] [PATCH v3 2/7] gcov: introduce hooks for the sysctl

So that other implementations of the sysctl can be added. Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky wrote: > On 01/18/2018 05:33 AM, Wei Liu wrote: >> On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote: >>> Wei, >>> >>> On 01/12/17 15:14, Juergen Gross wrote: Instead of locating the RSDP table below 1MB

Re: [Xen-devel] [PATCH] x86/acpi: process softirqs while printing CPU ACPI data

On 24/01/18 10:14, Roger Pau Monne wrote: > Or else the watchdog triggers on boxes with a huge number of CPUs > > Signed-off-by: Roger Pau Monné > Reported-by: Simon Crowe Acked-by: Andrew Cooper

Re: [Xen-devel] [MirageOS-devel] [Minios-devel] Preparing for GSoC and Outreachy : getting Outreach Program Projects into good shape

Looks good to me. The difficulties are all ‘medium’ though. Perhaps break up the “new execution targets” into medium/hard for the various backends? For example, Xen/ARM is probably easier than bare metal ARM, and I imagine HyperV is quite complex due to the extra coordination code that is

Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:

On 24/01/18 00:47, Stefano Stabellini wrote: > On Tue, 23 Jan 2018, Jan Beulich wrote: > On 23.01.18 at 01:41, wrote: >>> On 23/01/2018 00:38, Stefano Stabellini wrote: On Tue, 23 Jan 2018, Andrew Cooper wrote: > On 22/01/2018 23:48, Stefano Stabellini

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote: > On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky > wrote: > > On 01/18/2018 05:33 AM, Wei Liu wrote: > >> On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote: > >>> Wei, > >>> > >>> On 01/12/17

[Xen-devel] [PATCH] x86/shim: Fixes to replace_linear_mapping()

The function replace_va_mapping() has multiple issues: * It uses linear addresses, not virtual addresses. Fix its name. * Guest pagetables are allocated from the domheap not the xenheap, so need map_domain_page() to safely access. * put_page_and_type() should only apply to present mappings.

  1   2   >