Re: [Xen-devel] [PATCH 1/2] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling

Juergen Gross: > On 07/02/18 23:22, Simon Gaiser wrote: >> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple >> concurrent xenstore accesses") made a subtle change to the semantic of >> xenbus_dev_request_and_reply() and xenbus_transaction_end(). >> >> Before on an error response to

[Xen-devel] [qemu-mainline test] 119644: tolerable FAIL - PUSHED

flight 119644 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/119644/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 119544 test-armhf-armhf-libvirt-xsm 14

Re: [Xen-devel] [PATCH v2 05/15] xen/arm: Adapt smccc.h to be able to use it in assembly code

On Thu, 8 Feb 2018, Julien Grall wrote: > Signed-off-by: Julien Grall > Reviewed-by: Volodymyr Babchuk Acked-by: Stefano Stabellini > --- > Changes in v2: > - Add Volodymyr's reviewed-by > --- >

Re: [Xen-devel] [PATCH v3 02/17] xen/arm: vsmc: Implement SMCCC 1.1

On Thu, 15 Feb 2018, Julien Grall wrote: > The new SMC Calling Convention (v1.1) allows for a reduced overhead when > calling into the firmware, and provides a new feature discovery > mechanism. See "Firmware interfaces for mitigating CVE-2017-5715" > ARM DEN 00070A. > > Signed-off-by: Julien

Re: [Xen-devel] [PATCH v3 07/17] xen/arm: smccc: Add macros SMCCC_VERSION, SMCCC_VERSION_{MINOR, MAJOR}

On Thu, 15 Feb 2018, Julien Grall wrote: > Add macros SMCCC_VERSION, SMCCC_VERSION_{MINOR, MAJOR} to easily convert > between a 32-bit value and a version number. The encoding is based on > 2.2.2 in "Firmware interfaces for mitigation CVE-2017-5715" (ARM DEN 0070A). > > Also re-use them to define

Re: [Xen-devel] [PATCH v3 06/17] xen/arm64: Print a per-CPU message with the BP hardening method used

On Thu, 15 Feb 2018, Julien Grall wrote: > This will make easier to know whether BP hardening has been enabled for > a CPU and which method is used. > > Signed-off-by: Julien Grall > Reviewed-by: Volodymyr Babcuk Acked-by: Stefano Stabellini

Re: [Xen-devel] [PATCH v2 04/15] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

On Thu, 8 Feb 2018, Julien Grall wrote: > SMCCC 1.1 offers firmware-based CPU workarounds. In particular, > SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254 > (CVE-2017-5715). > > If the hypervisor has some mitigation for this issue, report that we > deal with it using

[Xen-devel] [linux-linus test] 119639: regressions - FAIL

flight 119639 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/119639/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324

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

flight 119648 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/119648/ 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

Re: [Xen-devel] [PATCH v3 01/17] xen/arm: vpsci: Add support for PSCI 1.1

On Thu, 15 Feb 2018, Julien Grall wrote: > At the moment, Xen provides virtual PSCI interface compliant with 0.1 > and 0.2. Since them, the specification has been updated and the latest > version is 1.1 (see ARM DEN 0022D). > > >From an implementation point of view, only PSCI_FEATURES is

Re: [Xen-devel] [PATCH v3 03/17] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

On Thu, 15 Feb 2018, Julien Grall wrote: > SMCCC 1.1 offers firmware-based CPU workarounds. In particular, > SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254 > (CVE-2017-5715). > > If the hypervisor has some mitigation for this issue, report that we > deal with it using

Re: [Xen-devel] [PATCH v3 04/17] xen/arm: Adapt smccc.h to be able to use it in assembly code

On Thu, 15 Feb 2018, Julien Grall wrote: > Signed-off-by: Julien Grall > Reviewed-by: Volodymyr Babchuk Acked-by: Stefano Stabellini > --- > Changes in v2: > - Add Volodymyr's reviewed-by > --- >

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-debianhvm-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-debianhvm-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [xen-unstable test] 119651: tolerable FAIL - PUSHED

flight 119651 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/119651/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail in 119592 pass in 119651

Re: [Xen-devel] [PATCH V5] x86/hvm: fix domain crash when CR3 has the noflush bit set

>>> On 19.02.18 at 09:48, wrote: > On 02/16/2018 01:17 PM, Jan Beulich wrote: > On 16.02.18 at 11:22, wrote: >>> The emulation layers of Xen lack PCID support, and as we only offer >>> PCID to HAP guests, all writes to CR3 are handled by

[Xen-devel] [PATCH v3 3/3] x86/xen: add pvh specific rsdp address retrieval function

Add pvh_get_root_pointer() for Xen PVH guests to communicate the address of the RSDP table given to the kernel via Xen start info. This makes the kernel boot again in PVH mode after on recent Xen the RSDP was moved to higher addresses. So up to that change it was pure luck that the legacy method

[Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

Signed-off-by: Jan Beulich --- a/CODING_STYLE +++ b/CODING_STYLE @@ -88,6 +88,26 @@ Braces should be omitted for blocks with if ( condition ) single_statement(); +Types +- + +Use basic C types and C standard mandated typedef-s where possible (and +with preference

[Xen-devel] Ping: [PATCH RFC v2] x86/domctl: Don't pause the whole domain if only getting vcpu state

Ping? > On Vi, 2017-10-06 at 13:02 +0300, Alexandru Isaila wrote: > > > > This patch adds the hvm_save_one_cpu_ctxt() function. > > It optimizes by only pausing the vcpu on all HVMSR_PER_VCPU save > > callbacks where only data for one VCPU is required. > > > > Signed-off-by: Alexandru Isaila

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

On 24/01/18 16:26, 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

Re: [Xen-devel] [PATCH V5] x86/hvm: fix domain crash when CR3 has the noflush bit set

On 02/16/2018 01:17 PM, Jan Beulich wrote: On 16.02.18 at 11:22, wrote: >> The emulation layers of Xen lack PCID support, and as we only offer >> PCID to HAP guests, all writes to CR3 are handled by hardware, >> except when introspection is involved. Consequently,

Re: [Xen-devel] [PATCH V5] x86/hvm: fix domain crash when CR3 has the noflush bit set

On 02/19/2018 10:53 AM, Jan Beulich wrote: On 19.02.18 at 09:48, wrote: >> On 02/16/2018 01:17 PM, Jan Beulich wrote: >> On 16.02.18 at 11:22, wrote: The emulation layers of Xen lack PCID support, and as we only offer PCID

[Xen-devel] [PATCH v3 0/3] xen: re-enable booting as Xen PVH guest

The Xen PVH boot protocol passes vital information to the kernel via a start_info block. One of the data transferred is the physical address of the RSDP table. Unfortunately PVH support in the kernel didn't use that passed address for RSDP, but relied on the legacy mechanism searching for the

[Xen-devel] [PATCH v3 2/3] x86/acpi: add a new x86_init_acpi structure to x86_init_ops

Add a new struct x86_init_acpi to x86_init_ops. For now it contains only one init function to get the RSDP table address. Cc: # 4.11 Signed-off-by: Juergen Gross --- arch/x86/include/asm/acpi.h | 7 +++ arch/x86/include/asm/x86_init.h | 9

Re: [Xen-devel] [RFC PATCH 36/49] ARM: new VGIC: Add SGIR register handler

Hi, On 09/02/18 14:39, Andre Przywara wrote: Triggering an IPI via this register is v2 specific, so the implementation lives entirely in vgic-mmio-v2.c. This is based on Linux commit 55cc01fb9004, written by Andre Przywara. Signed-off-by: Andre Przywara ---

Re: [Xen-devel] [RFC PATCH 38/49] ARM: new VGIC: handle hardware mapped IRQs

Hi, On 09/02/18 14:39, Andre Przywara wrote: The VGIC supports virtual IRQs to be connected to a hardware IRQ, so when a guest EOIs the virtual interrupt, it affects the state of that corresponding interrupt on the hardware side at the same time. Implement the interface that the Xen arch/core

[Xen-devel] [PATCH] shim: allow building of just the shim with build-ID-incapable linker

The ELF note the shim build inserts causes mkelf32 to choke on the second program header. However, the output of mkelf32 isn't really needed when building inside tools/firmware/ - an attempt to build it is made solely because of a wrong dependency. Further changes to the make logic will be needed

[Xen-devel] [xen-4.7-testing test] 119626: tolerable FAIL - PUSHED

flight 119626 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119626/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 119569 pass in 119626

Re: [Xen-devel] [PATCH] shim: allow building of just the shim with build-ID-incapable linker

>>> On 19.02.18 at 15:56, wrote: > I also assume that passing --notes to mkelf32 when building the shim > (regardless of whether the linker supports build ID or not) should > also fix the issue? I guess so, but I simply didn't have the time to figure out (and test) yet

Re: [Xen-devel] [PATCH v3] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

>>> On 19.02.18 at 15:23, wrote: > We're noticing a reproducible system boot hang on certain > post-Skylake platforms where the BIOS is configured in > legacy boot mode with x2APIC disabled. The system stalls > immediately after writing the first SMP initialization >

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

Jan Beulich writes ("[PATCH RFC] CODING_STYLE: document intended usage of types"): > +Types > +- > + > +Use basic C types and C standard mandated typedef-s where possible (and > +with preference in this order). This in particular means to avoid u8, > +u16, etc despite those types continuing

Re: [Xen-devel] [RFC PATCH 28/49] ARM: new VGIC: Add GICv2 MMIO handling framework

Hi, On 16/02/18 15:39, Julien Grall wrote: > Hi Andre, > > On 09/02/18 14:39, Andre Przywara wrote: >> Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers >> using the initializer macros provided by the VGIC MMIO framework. >> Provide a function to register the GICv2 distributor

Re: [Xen-devel] [RFC PATCH 43/49] ARM: new VGIC: Add preliminary stub implementations

Hi, On 09/02/18 14:39, Andre Przywara wrote: The Xen core code requires an interrupt controller emulation to implement arch_move_irqs(), to move the affinity of an hardware mapped virtual IRQ to another core. In the moment we don't implement this physical-follow-virtual regime in our new VGIC,

Re: [Xen-devel] [PATCH v2 1/2] x86/hvm: introduce cr_mask to store trapped bits of CR accesses

On 19/02/18 15:04, Roger Pau Monné wrote: > On Fri, Feb 16, 2018 at 12:49:57PM +, Andrew Cooper wrote: >> On 16/02/18 12:10, Roger Pau Monne wrote: >>> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h >>> index d93166fb92..811d4c10ae 100644 >>> ---

Re: [Xen-devel] [RFC PATCH 30/49] ARM: new VGIC: Add ENABLE registers handlers

On 19/02/18 12:41, Andre Przywara wrote: Hi, Hi, On 16/02/18 16:57, Julien Grall wrote: On 09/02/18 14:39, Andre Przywara wrote: +    spin_lock_irqsave(>lock, flags); +    if ( enable ) +    { +    gic_set_irq_type(desc, irq_type == VGIC_CONFIG_LEVEL ? +

[Xen-devel] [PATCH v4 2/4] x86/clang: restore integrated assembler usage with indirect thunks

If the required features are meet by the integrated clang assembler (support for .includes and propagation of .macro-s between asm()-s) do not disable it. Only switch off the non integrated assembler for assembly file, like it was done prior to "x86: Support indirect thunks from assembly code".

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

>>> On 19.02.18 at 14:39, wrote: > Jan Beulich writes ("Re: [PATCH RFC] CODING_STYLE: document intended usage of > types"): >> Types to be used for addresses - from a really generic pov - >> depend on the architecture. Iirc there are some where a signed >> type is the

[Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

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

[Xen-devel] [PATCH v4 0/4] clang fixes

Hello, The following series re-enable the integrated clang assembler when the features required in order to build Xen are available. First 2 patches remove the unconditional addition of -no-integrated-as to CFLAGS (only adding it to AFLAGS like it was done before). Finally patches 3 and 4 remove

[Xen-devel] [PATCH v4 1/4] build: filter out command line assembler arguments

If the assembler is not used. This happens when using cc -E or cc -S for example. GCC will just ignore the -Wa,... when the assembler is not called, but clang will complain loudly and fail. Also enable passing -Wa,-I$(BASEDIR)/include to clang now that it's safe to do so. Signed-off-by: Roger

[Xen-devel] [PATCH v3] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

We're noticing a reproducible system boot hang on certain post-Skylake platforms where the BIOS is configured in legacy boot mode with x2APIC disabled. The system stalls immediately after writing the first SMP initialization sequence into APIC ICR. The cause of the problem is watchdog NMI handler

Re: [Xen-devel] [PATCH] shim: allow building of just the shim with build-ID-incapable linker

On Mon, Feb 19, 2018 at 06:23:09AM -0700, Jan Beulich wrote: > The ELF note the shim build inserts causes mkelf32 to choke on the > second program header. However, the output of mkelf32 isn't really > needed when building inside tools/firmware/ - an attempt to build it is > made solely because of

Re: [Xen-devel] [PATCH v2 1/2] x86/hvm: introduce cr_mask to store trapped bits of CR accesses

On Fri, Feb 16, 2018 at 12:49:57PM +, Andrew Cooper wrote: > On 16/02/18 12:10, Roger Pau Monne wrote: > > diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h > > index d93166fb92..811d4c10ae 100644 > > --- a/xen/include/asm-x86/hvm/vcpu.h > > +++

Re: [Xen-devel] [RFC PATCH 35/49] ARM: new VGIC: Add TARGET registers handlers

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The target register handlers are v2 emulation specific, so their implementation lives entirely in vgic-mmio-v2.c. We copy the old VGIC behaviour of assigning an IRQ to the first VCPU set in the target mask instead of making it possibly pending

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

>>> On 19.02.18 at 12:46, wrote: > Jan Beulich writes ("[PATCH RFC] CODING_STYLE: document intended usage of > types"): >> +Types >> +- >> + >> +Use basic C types and C standard mandated typedef-s where possible (and >> +with preference in this order). This in

[Xen-devel] [PATCH v1 1/2] asm-x86/monitor: Add MONITOR_EVENT_INTERRUPT to common capabilities

Signed-off-by: Alexandru Isaila --- xen/include/asm-x86/monitor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h index 59a2610..7a9e1e8 100644 --- a/xen/include/asm-x86/monitor.h +++

[Xen-devel] [PATCH v1 2/2] hvm/svm: Implement CPUID events

At this moment the CPUID events for the AMD architecture are not forwarded to the monitor layer. This patch adds the CPUID event to the common capabilities and then forwards the event to the monitor layer. Signed-off-by: Alexandru Isaila --- xen/arch/x86/hvm/svm/svm.c

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

On 19/02/18 10:47, Sander Eikelenboom wrote: > On 24/01/18 16:26, 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

Re: [Xen-devel] [PATCH v3 0/3] xen: re-enable booting as Xen PVH guest

On 2/19/2018 11:09 AM, Juergen Gross wrote: The Xen PVH boot protocol passes vital information to the kernel via a start_info block. One of the data transferred is the physical address of the RSDP table. Unfortunately PVH support in the kernel didn't use that passed address for RSDP, but relied

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

flight 119602 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/119602/ 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] [PATCH v3 1/3] acpi: introduce acpi_arch_get_root_pointer() for getting rsdp address

Add an architecture specific function to get the address of the RSDP table. Per default it will just return 0 indicating falling back to the current mechanism. Cc: # 4.11 Signed-off-by: Juergen Gross --- drivers/acpi/osl.c | 5 -

[Xen-devel] [PATCH v2] x86/msr: add Raw and Host domain policies

Raw policy contains the actual values from H/W MSRs. Add PLATFORM_INFO msr to the policy during probe_cpuid_faulting(). Host policy may have certain features disabled if Xen decides not to use them. For now, make Host policy equal to Raw policy with cpuid_faulting availability dependent on

Re: [Xen-devel] [RFC PATCH 34/49] ARM: new VGIC: Add CONFIG registers handlers

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The config register handlers are shared between the v2 and v3 emulation, so their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. This is based on Linux commit 79717e4ac09c, written by Andre

Re: [Xen-devel] [RFC PATCH 37/49] ARM: new VGIC: Add SGIPENDR register handlers

Hi, On 09/02/18 14:39, Andre Przywara wrote: As this register is v2 specific, its implementation lives entirely in vgic-mmio-v2.c. This register allows setting the source mask of an IPI. This is based on Linux commit ed40213ef9b0, written by Andre Przywara. Signed-off-by: Andre Przywara

Re: [Xen-devel] [RFC PATCH 35/49] ARM: new VGIC: Add TARGET registers handlers

Hi, On 09/02/18 14:39, Andre Przywara wrote: The target register handlers are v2 emulation specific, so their implementation lives entirely in vgic-mmio-v2.c. We copy the old VGIC behaviour of assigning an IRQ to the first VCPU set in the target mask instead of making it possibly pending on

Re: [Xen-devel] [RFC PATCH 44/49] ARM: new VGIC: vgic-init: register VGIC

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: This patch implements the function which is called by Xen when it wants to register the virtual GIC. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic/vgic-init.c | 62 +++

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

>>> On 19.02.18 at 14:12, wrote: > On 19/02/18 08:44, Jan Beulich wrote: >> --- a/CODING_STYLE >> +++ b/CODING_STYLE >> @@ -88,6 +88,26 @@ Braces should be omitted for blocks with >> if ( condition ) >> single_statement(); >> >> +Types >> +- >> + >> +Use

Re: [Xen-devel] [PATCH v3 0/3] xen: re-enable booting as Xen PVH guest

On Mon, Feb 19, 2018 at 12:27 PM, Rafael J. Wysocki wrote: > On 2/19/2018 11:09 AM, Juergen Gross wrote: >> >> The Xen PVH boot protocol passes vital information to the kernel via >> a start_info block. One of the data transferred is the physical address >> of the RSDP

Re: [Xen-devel] [PATCH] x86/PV: avoid indirect call/thunk in I/O emulation

On 19/02/18 07:50, Jan Beulich wrote: On 16.02.18 at 18:02, wrote: >> On 16/02/18 16:21, Jan Beulich wrote: >> On 16.02.18 at 16:50, wrote: On 16/02/18 08:00, Jan Beulich wrote: On 15.02.18 at 17:53,

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

flight 119592 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/119592/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken in 119521 build-armhf-pvops

Re: [Xen-devel] [RFC PATCH 41/49] ARM: new VGIC: dump virtual IRQ info

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: When we dump guest state on the Xen console, we also print the state of IRQs that are on a VCPU. Add the code to dump the state of an IRQ handled by the new VGIC. Signed-off-by: Andre Przywara ---

Re: [Xen-devel] [RFC PATCH 30/49] ARM: new VGIC: Add ENABLE registers handlers

Hi, On 16/02/18 16:57, Julien Grall wrote: > Hi Andre, > > On 09/02/18 14:39, Andre Przywara wrote: >> As the enable register handlers are shared between the v2 and v3 >> emulation, their implementation goes into vgic-mmio.c, to be easily >> referenced from the v3 emulation as well later. >> >>

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

On 19/02/18 08:44, Jan Beulich wrote: > Signed-off-by: Jan Beulich > > --- a/CODING_STYLE > +++ b/CODING_STYLE > @@ -88,6 +88,26 @@ Braces should be omitted for blocks with > if ( condition ) > single_statement(); > > +Types > +- > + > +Use basic C types and C

Re: [Xen-devel] [PATCH v2] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

>>> On 16.02.18 at 18:46, wrote: > We're noticing a reproducible system boot hang on certain > post-Skylake platforms where the BIOS is configured in > legacy boot mode with x2APIC disabled. The system stalls > immediately after writing the first SMP initialization >

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

Jan Beulich writes ("Re: [PATCH RFC] CODING_STYLE: document intended usage of types"): > Types to be used for addresses - from a really generic pov - > depend on the architecture. Iirc there are some where a signed > type is the more natural representation, while on x86 and ARM > we'd certainly

Re: [Xen-devel] [PATCH v1 2/2] hvm/svm: Implement CPUID events

On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila wrote: > At this moment the CPUID events for the AMD architecture are not > forwarded to the monitor layer. > > This patch adds the CPUID event to the common capabilities and then > forwards the event to the monitor layer.

Re: [Xen-devel] [PATCH v1 2/2] hvm/svm: Implement CPUID events

On 02/19/2018 05:25 PM, Tamas K Lengyel wrote: > On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila > wrote: >> At this moment the CPUID events for the AMD architecture are not >> forwarded to the monitor layer. >> >> This patch adds the CPUID event to the common

Re: [Xen-devel] [PATCH v3] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

>>> On 19.02.18 at 16:20, wrote: > On 19/02/18 15:18, Jan Beulich wrote: > On 19.02.18 at 15:23, wrote: >>> We're noticing a reproducible system boot hang on certain >>> post-Skylake platforms where the BIOS is configured in >>> legacy

Re: [Xen-devel] [PATCH v2] x86/msr: add Raw and Host domain policies

>>> On 19.02.18 at 12:29, wrote: > Raw policy contains the actual values from H/W MSRs. Add PLATFORM_INFO > msr to the policy during probe_cpuid_faulting(). > > Host policy may have certain features disabled if Xen decides not > to use them. For now, make Host policy

Re: [Xen-devel] [RFC PATCH 45/49] ARM: new VGIC: vgic-init: implement vgic_init

On 19/02/18 15:53, Andre Przywara wrote: Hi, On 19/02/18 13:21, Julien Grall wrote: Hi, On 09/02/18 14:39, Andre Przywara wrote: This patch allocates and initializes the data structures used to model the vgic distributor and virtual cpu interfaces. At that stage the number of IRQs and

Re: [Xen-devel] [PATCH v4 1/4] build: filter out command line assembler arguments

On Mon, Feb 19, 2018 at 08:43:51AM -0700, Jan Beulich wrote: > >>> On 19.02.18 at 15:16, wrote: > > --- > > xen/arch/x86/Makefile | 6 +++--- > > xen/arch/x86/Rules.mk | 5 + > > xen/include/Makefile | 2 +- > > 3 files changed, 5 insertions(+), 8 deletions(-) > >

Re: [Xen-devel] [PATCH v4 1/4] build: filter out command line assembler arguments

>>> On 19.02.18 at 17:05, wrote: > On Mon, Feb 19, 2018 at 08:43:51AM -0700, Jan Beulich wrote: >> >>> On 19.02.18 at 15:16, wrote: >> > --- >> > xen/arch/x86/Makefile | 6 +++--- >> > xen/arch/x86/Rules.mk | 5 + >> > xen/include/Makefile | 2 +-

[Xen-devel] Getting Hypercall [op = 0x0040001a ] on trace 

Hello, Im getting this Hypercall [op = 0x0040001a ] on xen trace but can't figure out which operation this is. Using old Xen 4.4.1. Looking at documentation and also using grep into source code couldn't figure out which hypercall this is. Can someone help clarify this? -- Atenciosamente,

Re: [Xen-devel] Getting Hypercall [op = 0x0040001a ] on trace 

On Mon, Feb 19, 2018 at 04:23:33PM +, Charles Gonçalves wrote: > Hello, > > Im getting this Hypercall [op = 0x0040001a ] on xen trace but can't figure > out which operation this is. > > Using old Xen 4.4.1. > Looking at documentation and also using grep into source code couldn't > figure

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On Fri, Feb 16, 2018 at 04:35:14PM -0500, Rich Persaud wrote: > On Feb 16, 2018, at 14:02, Andrew Cooper wrote: > > > > IMO, PCI Passthrough is a trainwreck, and it is a miracle it functions > > at all. > > Would that statement apply to other hypervisors like KVM,

Re: [Xen-devel] [PATCH] x86/xpti: avoid copying L4 page table contents when possible

On 19/02/18 17:59, Jan Beulich wrote: On 15.02.18 at 13:52, wrote: >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -510,6 +510,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn) >> void write_ptbase(struct vcpu *v) >> { >> write_cr3(v->arch.cr3); >> +/*

Re: [Xen-devel] [RFC PATCH 31/49] ARM: new VGIC: Add PENDING registers handlers

On 19/02/18 15:32, Andre Przywara wrote: Hi, Hi Andre, On 16/02/18 17:16, Julien Grall wrote: On 09/02/18 14:39, Andre Przywara wrote: + +    /* Loop over all IRQs affected by this read */ +    for ( i = 0; i < len * 8; i++ ) +    { +    struct vgic_irq *irq =

Re: [Xen-devel] [PATCH v4 1/4] build: filter out command line assembler arguments

>>> On 19.02.18 at 15:16, wrote: > --- > xen/arch/x86/Makefile | 6 +++--- > xen/arch/x86/Rules.mk | 5 + > xen/include/Makefile | 2 +- > 3 files changed, 5 insertions(+), 8 deletions(-) What about the "%.i: %.c", "%.s: %.c", and "%.s: %.S" rules near the end of

Re: [Xen-devel] [PATCH v4 4/4] build/clang: add a check whether the assembler supports .skip with labels

>>> On 19.02.18 at 15:16, wrote: > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -72,7 +72,11 @@ AFLAGS-y+= -D__ASSEMBLY__ > > # Older clang's built-in assembler doesn't understand .skip with labels: > # https://bugs.llvm.org/show_bug.cgi?id=27369 >

Re: [Xen-devel] Getting Hypercall [op = 0x0040001a ] on trace 

On Mon, Feb 19, 2018 at 04:23:33PM +, Charles Gonçalves wrote: > Hello, > > Im getting this Hypercall [op = 0x0040001a ] on xen trace but can't figure > out which operation this is. I guess 0x1a is the hypercall number (26 in decimal), which matches to __HYPERVISOR_mmuext_op. See

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

flight 119657 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/119657/ 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 v4 1/4] build: filter out command line assembler arguments

On Mon, Feb 19, 2018 at 09:14:30AM -0700, Jan Beulich wrote: > >>> On 19.02.18 at 17:05, wrote: > > On Mon, Feb 19, 2018 at 08:43:51AM -0700, Jan Beulich wrote: > >> >>> On 19.02.18 at 15:16, wrote: > >> > --- > >> > xen/arch/x86/Makefile | 6 +++--- >

Re: [Xen-devel] [PATCH v4 2/4] x86/clang: restore integrated assembler usage with indirect thunks

On Mon, Feb 19, 2018 at 08:57:15AM -0700, Jan Beulich wrote: > >>> On 19.02.18 at 15:16, wrote: > > --- a/xen/arch/x86/Rules.mk > > +++ b/xen/arch/x86/Rules.mk > > @@ -44,3 +44,17 @@ endif > > > > # Set up the assembler include path properly for older toolchains. > >

Re: [Xen-devel] [RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver

On Tue, Feb 13, 2018 at 05:49:59PM -0800, Dongwon Kim wrote: > This patch series contains the implementation of a new device driver, > hyper_DMABUF driver, which provides a way to expand the boundary of > Linux DMA-BUF sharing to across different VM instances in Multi-OS platform > enabled by a

Re: [Xen-devel] [PATCH v4 2/4] x86/clang: restore integrated assembler usage with indirect thunks

On Mon, Feb 19, 2018 at 02:16:18PM +, Roger Pau Monne wrote: > If the required features are meet by the integrated clang assembler ^ met ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On 16/02/18 20:02, Andrew Cooper wrote: > On 16/02/18 18:51, Marek Marczykowski-Górecki wrote: >> On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote: >>> On 16/02/18 17:48, Marek Marczykowski-Górecki wrote: Hi, As in the subject, the guest crashes on boot, before kernel

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On Mon, Feb 19, 2018 at 06:23:40PM +0100, Juergen Gross wrote: > On 16/02/18 20:54, Marek Marczykowski-Górecki wrote: > > Just before the BUG(), there is a call to xen_raw_console_write(). But > > apparently it was too early... > > Depends. > > With a debug enabled hypervisor and appropriate log

[Xen-devel] [PATCH v4] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

We're noticing a reproducible system boot hang on certain Skylake platforms where the BIOS is configured in legacy boot mode with x2APIC disabled. The system stalls immediately after writing the first SMP initialization sequence into APIC ICR. The cause of the problem is watchdog NMI handler

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On 16/02/18 20:54, Marek Marczykowski-Górecki wrote: > On Fri, Feb 16, 2018 at 07:02:39PM +, Andrew Cooper wrote: >> On 16/02/18 18:51, Marek Marczykowski-Górecki wrote: >>> On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote: On 16/02/18 17:48, Marek Marczykowski-Górecki wrote:

Re: [Xen-devel] Getting Hypercall [op = 0x0040001a ] on trace 

On Mon, Feb 19, 2018 at 05:13:11PM +, Wei Liu wrote: > On Mon, Feb 19, 2018 at 04:23:33PM +, Charles Gonçalves wrote: > > Hello, > > > > Im getting this Hypercall [op = 0x0040001a ] on xen trace but can't figure > > out which operation this is. > > > > Using old Xen 4.4.1. > > Looking

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On 19/02/18 18:29, Marek Marczykowski-Górecki wrote: > On Mon, Feb 19, 2018 at 06:23:40PM +0100, Juergen Gross wrote: >> On 16/02/18 20:54, Marek Marczykowski-Górecki wrote: >>> Just before the BUG(), there is a call to xen_raw_console_write(). But >>> apparently it was too early... >> >> Depends.

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On 19/02/18 17:46, Juergen Gross wrote: > On 19/02/18 18:29, Marek Marczykowski-Górecki wrote: >> On Mon, Feb 19, 2018 at 06:23:40PM +0100, Juergen Gross wrote: >>> On 16/02/18 20:54, Marek Marczykowski-Górecki wrote: Just before the BUG(), there is a call to xen_raw_console_write(). But

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On Mon, 19 Feb 2018, Julien Grall wrote: > On 19/02/2018 21:05, Stefano Stabellini wrote: > > On Mon, 19 Feb 2018, Julien Grall wrote: > > > On 19/02/2018 20:28, Stefano Stabellini wrote: > > > > On Sat, 17 Feb 2018, Julien Grall wrote: > > > > > Hi, > > > > > > > > > > On 17/02/2018 00:31,

[Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

On big.LITTLE systems the cacheline size might differ between big and LITTLE cores. Instead of reading the cacheline size once at boot, read it as needed from the system registers. Suggested-by: Julien Grall Signed-off-by: Stefano Stabellini ---

[Xen-devel] [PATCH v2 4/6] xen/arm: make vpidr per vcpu

On big.LITTLE systems not all cores have the same midr. Instead of storing only one vpidr per domain, make it per vcpu and initialize it to the value of the midr of the pcpu where the vcpu will run. This way, assuming that the vcpu has been created with the right pcpu affinity, the guest will be

[Xen-devel] [PATCH v2 3/6] xen/arm: read ACTLR on the pcpu where the vcpu will run

On big.LITTLE systems not all cores have the same ACTLR. Instead of reading ACTLR and setting v->arch.actlr in vcpu_initialise, do it later on the same pcpu where the vcpu will run. This way, assuming that the vcpu has been created with the right pcpu affinity, the guest will be able to read the

[Xen-devel] [PATCH v2 1/6] xen/arm: Park CPUs with a MIDR different from the boot CPU.

From: Julien Grall From: Julien Grall Xen does not properly support big.LITTLE platform. All vCPUs of a guest will always have the MIDR of the boot CPU (see arch_domain_create). At best the guest may see unreliable performance (vCPU switching between

[Xen-devel] [PATCH v2 6/6] xen/arm: update the docs about heterogeneous computing

Introduce a new document about big.LITTLE and update the documentation of hmp-unsafe. Also update the warning messages to point users to the docs. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: konrad.w...@oracle.com CC: t...@xen.org CC: wei.l...@citrix.com

[Xen-devel] [PATCH v2 2/6] xen/arm: make processor a per cpu variable

There can be processors of different kinds on a single system. Make processor a per_cpu variable pointing to the right processor type for each core. Suggested-by: Julien Grall Signed-off-by: Stefano Stabellini --- Changes in v2: - add patch ---

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On 19/02/2018 20:28, Stefano Stabellini wrote: On Sat, 17 Feb 2018, Julien Grall wrote: Hi, On 17/02/2018 00:31, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: On 16/02/2018 21:15, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: On 16/02/2018 20:50,

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On Mon, 19 Feb 2018, Julien Grall wrote: > On 19/02/2018 20:28, Stefano Stabellini wrote: > > On Sat, 17 Feb 2018, Julien Grall wrote: > > > Hi, > > > > > > On 17/02/2018 00:31, Stefano Stabellini wrote: > > > > On Fri, 16 Feb 2018, Julien Grall wrote: > > > > > On 16/02/2018 21:15, Stefano

  1   2   >