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
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 host-ins
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
test-amd64-amd64-x
> 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 informat
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 the
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 preserved
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 Zy
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 inva
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
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 c
flight 118312 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118312/
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 1
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/include/asm-arm/processor.h | 4
> 1 file
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.
>
>
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 Wed, 17 Jan 2018, Stefano
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 - w
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
>> that we cannot take a br
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 versi
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 Jan 2018, Lars Kurth 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 Jan 2018, Lars Kurth wrote:
> > > >Regarding README.source, this is covering file and contain t
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
__
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
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 purpos
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
---
xen/include/asm-x86/asm_defns.h | 2 +-
1 file changed,
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 1
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 vsmc.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 fun
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.
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.
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
> > +++ b/docs/misc
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.
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 distrib
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.
While
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 c
On ARM the maximum number of IRQs is a constant, but we share it being
a variable to match x86. Since we are not supposed to alter it, let's
mark it as "const" to avoid accidental change.
Suggested-by: Julien Grall
Signed-off-by: Andre Przywara
---
xen/arch/arm/irq.c| 2 +-
xen/include/
In event.h we very deeply dive into the VGIC to learn if an event for
a guest is pending.
Rework that function to abstract the VGIC specific part out. Also
reorder the queries there, as we only actually need to check for the
event channel if there are no other pending IRQs.
Signed-off-by: Andre Pr
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/arch/arm/domain.c | 1 +
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 said
In gic_restore_pending_irqs() we push our pending virtual IRQs into the
list registers. This function is called once from gic_inject(), just
before we return to the guest, but also in gic_restore_state(), when
we context-switch a VCPU. Having a closer look it turns out that the
later call is not ne
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
Acked-by: Stefano St
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 separate
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
Reviewed-by: Stefano Stab
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
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
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 i
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 __cpumask_set_cpu instead o
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
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, 23 Jan 2018, Andrew Cooper wr
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
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 17
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 patch is using libxl__device_ki
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 wrote:
> > On 22/01/2018 23:4
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
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. Al
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 ++--
tools/libxl/libxl_device.c | 7 ---
tools/libxl/libxl_internal.h | 12 +++---
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.
Signed-off-by: Oleksandr Gryts
From: Oleksandr Grytsov
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/libxl/libxl_internal.h | 38 ++
tools/libxl/libxl_nic.c | 22 +-
tools/libxl/libxl_vdispl.c | 35 +--
3 files chan
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 +++
tools/libxl/libxl_console.c | 18 +++---
too
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 device XS entry
libxl: use
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 understand this: What if I
Hi Julien,
> On 18 Jan 2018, at 10:56, Julien Grall wrote:
>
> On 17/01/18 14:31, Lars Kurth wrote:
>> Hi Julien,
>
> Hi Lars,
>
...
>> Normally this isn't a problem: only if we ever have to relicense the code or
>> if someone does code archeology
>> When we relicensed the ACPI builder, it c
Hi Andre,
On 24/01/18 16:58, Andre Przywara wrote:
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
Hi,
On 24/01/18 16:32, Julien Grall wrote:
> 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 proper
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 plac
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 a check to define CONF
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
> +++ b/xen/include/xen/sched.h
> @@ -627,11 +627,12 @@ voi
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 har
>>> 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 +627,12 @@ void __domain_crash(struct domain *d);
*
>>> 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.
>>>
>>> Furthermore, diagnostic information around calls is inconsist
>>> 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 done in each one? I'd e
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 f
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
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 t
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 information around calls is inc
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 rea
>>> 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 a check to define CONFIG_INDIRECT_THUNK to 0 if not defined, so
> that using .if CONFIG_INDIREC
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 information around calls is inconsistent and
>> occasionally unhelpful. (e.g.
On 24/01/18 17:10, Boris Ostrovsky wrote:
> On 01/24/2018 10:26 AM, George Dunlap wrote:
>> On Wed, Jan 24, 2018 at 3:20 PM, Juergen Gross wrote:
>>> 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 Gro
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 places, along with
a comment to explain the reasons.
Signed-
On 01/24/2018 10:26 AM, George Dunlap wrote:
> On Wed, Jan 24, 2018 at 3:20 PM, Juergen Gross wrote:
>> 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
>>> 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 information around calls is inconsistent and
> occasionally unhelpful. (e.g. diagnosing logs from the field which might
(+ 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 the architected ones. But those properties are
optional and on
On 01/24/2018 03:48 PM, Andrew Cooper wrote:
> On 24/01/18 15:43, Jan Beulich wrote:
> On 24.01.18 at 16:02, wrote:
>>> 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 co
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 a check to define CONFIG_INDIRECT_THUNK to 0 if not defined, so
that using .if CONFIG_INDIRECT_THUNK is always correct.
This suppresses th
The use of __LINE__ in a printk() is problematic for livepatching, as it
causes unnecessary binary differences.
Furthermore, diagnostic information around calls is inconsistent and
occasionally unhelpful. (e.g. diagnosing logs from the field which might be
release builds, or likely without exact
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.
In order to fix this always include indirect_thunk_asm.h in the same
asm declaration where it's being used.
Signed-off-by: Roger Pau Monné
---
Cc:
Hello,
The following two patches fix building Xen with clang and the indirect
thunk.
Patch 2 is not strictly needed, because when building with clang we
still compile assembly only files with -no-integrated-as, but it's a
nice to have so that we don't regress more in assembly only code.
Thanks,
On 24/01/18 15:43, Jan Beulich wrote:
On 24.01.18 at 16:02, wrote:
>> 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, ther
On 24/01/18 15:41, Jan Beulich wrote:
On 24.01.18 at 15:11, wrote:
>> 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
>>> On 24.01.18 at 16:02, wrote:
> 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
>>> On 24.01.18 at 15:11, wrote:
> 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 t
On Wed, Jan 24, 2018 at 3:20 PM, Juergen Gross wrote:
> 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 +0
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:
> On Wed, Jan 24, 2018 at 2:41 A
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 productio
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
wrote:
> On 01/18/2
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
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 t
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 1
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 t
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 arc
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 f
1 - 100 of 186 matches
Mail list logo