[Xen-devel] [xen-unstable test] 122660: regressions - trouble: blocked/broken/fail/pass

flight 122660 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/122660/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken

Re: [Xen-devel] domain_crash_sync vs "plain crash"

@Andrew, Despite SCHED_OP, that I've blacklisted, which one came to mind? On Mon, May 7, 2018 at 5:13 AM Andrew Cooper wrote: > On 07/05/2018 08:09, Jan Beulich wrote: > On 07.05.18 at 03:06, wrote: > >> When I'm performing some

Re: [Xen-devel] domain_crash_sync vs "plain crash"

"That is, without (physical or virtual, depending on component) serial console you're often unlikely to actually observe any messages connected to the crash." I do not have any experience with serial console interaction on linux. Can you list some examples for both cases (virtual| physical), I'll

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Fri, 11 May 2018, Dario Faggioli wrote: > On Fri, 2018-05-11 at 14:08 +0100, Julien Grall wrote: > > The whole idea here is we have only one place taking the decision and > > we > > don't spread BUG_ON()/panic/stop_cpu everywhere. The benefit is > > having > > only one place to fix over

Re: [Xen-devel] [PATCH 5/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

On 5/9/2018 2:58 AM, Julien Grall wrote: > > > On 09/05/2018 09:30, Manish Jaggi wrote: >> >> >> On 04/19/2018 04:24 PM, Manish Jaggi wrote: >>> Sorry for top posting, >>> >>> is someone working on the comments on this patch? >>> >>> -Manish >>> >> If no one is working this code anymore, I would

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

flight 122659 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122659/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 122512

Re: [Xen-devel] [PATCH] viridian: fix cpuid leaf 0x40000003

On 11/05/18 18:18, Andrew Cooper wrote: > On 11/05/18 15:48, Paul Durrant wrote: >> The response to viridian leaf 3 needs to split a 64-bit mask across EAX and >> EBX, with the low order 32 bits in EAX and the high order 32 bits in EBX. >> To facilitate this a union of two uint32_t values and the

Re: [Xen-devel] [PATCH v3 1/2] doc: correct livepatch.markdown syntax

On 11/05/18 18:56, Konrad Rzeszutek Wilk wrote: > On Tue, May 08, 2018 at 11:51:47AM +0100, George Dunlap wrote: >> On 05/08/2018 07:47 AM, Juergen Gross wrote: >>> "make -C docs all" fails due to incorrect markdown syntax in >>> livepatch.markdown. Correct it. >>> >>> Signed-off-by: Juergen Gross

Re: [Xen-devel] [PATCH v3 1/2] doc: correct livepatch.markdown syntax

On Tue, May 08, 2018 at 11:51:47AM +0100, George Dunlap wrote: > On 05/08/2018 07:47 AM, Juergen Gross wrote: > > "make -C docs all" fails due to incorrect markdown syntax in > > livepatch.markdown. Correct it. > > > > Signed-off-by: Juergen Gross > > Reviewed-by: Konrad

[Xen-devel] [PATCH for-4.11 v4 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

The tool covers step 2 of the following workflow Step 1: git format-patch ... -o ... Step 2: ./scripts/add_maintainers.pl -d This overwrites *.patch files in Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchxm I manually tested all options and the most common

Re: [Xen-devel] Draft NVDIMM proposal

[ adding linux-nvdimm ] Great write up! Some comments below... On Wed, May 9, 2018 at 10:35 AM, George Dunlap wrote: > Dan, > > I understand that you're the NVDIMM maintainer for Linux. I've been > working with your colleagues to try to sort out an architecture to

[Xen-devel] [PATCH for-4.11 v4 0/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

This version of this series addresses all comments on the mailing list, as well as some feedback I got in various personal conversations and/or on IRC. For the people who asked for specific features/workflows: Ian Jackson: use ./scripts/add_maintainers.pl -p none [-c header] Reads CCs from

Re: [Xen-devel] [PATCH] viridian: fix cpuid leaf 0x40000003

On 11/05/18 15:48, Paul Durrant wrote: > The response to viridian leaf 3 needs to split a 64-bit mask across EAX and > EBX, with the low order 32 bits in EAX and the high order 32 bits in EBX. > To facilitate this a union of two uint32_t values and the mask (type > HV_PARTITION_PRIVILEGE_MASK) is

Re: [Xen-devel] [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer

On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote: > On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote: >> On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Add missing string

[Xen-devel] Xen 4.11 RC4

Hi all, Xen 4.11 rc4 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.11.0-rc4 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.11.0-rc4/xen-4.11.0-rc4.tar.gz And the signature is at:

[Xen-devel] staging-4.6 seems to be broken

osstest service owner writes ("[xen-4.6-testing test] 122657: regressions - FAIL"): > flight 122657 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/122657/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be

[Xen-devel] [OSSTEST PATCH] ts-xen-build: run `make build' before `make', by default

The Xen build system has some quirks. One of them is that `make' is a version of `make dist' which is a version of `make install', which runs `make install' in each subdir - but there are subdirs where `make install' is a no-op which does not depend on `make build'. Also, `make all' does not do

[Xen-devel] [PATCH] viridian: fix cpuid leaf 0x40000003

The response to viridian leaf 3 needs to split a 64-bit mask across EAX and EBX, with the low order 32 bits in EAX and the high order 32 bits in EBX. To facilitate this a union of two uint32_t values and the mask (type HV_PARTITION_PRIVILEGE_MASK) is allocated on stack as follows: union {

Re: [Xen-devel] [PATCH 01/10] x86/spec_ctrl: Read MSR_ARCH_CAPABILITIES only once

On Fri, May 11, 2018 at 11:38:05AM +0100, Andrew Cooper wrote: > Make it available from the beginning of init_speculation_mitigations(), and > pass it into appropriate functions. Fix an RSBA typo while moving the > affected comment. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Fri, 2018-05-11 at 15:44 +0200, Mirela Simonovic wrote: > Hi Dario and Julien, > Err... you've dropped the list and everyone else but me. Re-adding... > Thanks for the feedback to both. > You're welcome. :-) > I think we need to roll back here. I > believe the root cause of this is an

Re: [Xen-devel] [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer

On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko wrote: > > From: Oleksandr Andrushchenko > > > > Add missing string constants for {feature|request}-raw-pointer > > to

Re: [Xen-devel] [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer

On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Add missing string constants for {feature|request}-raw-pointer > to align with the rest of the interface file. > > Fixes 7868654ff7fe ("kbdif: Define

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Fri, 2018-05-11 at 14:08 +0100, Julien Grall wrote: > The whole idea here is we have only one place taking the decision and > we > don't spread BUG_ON()/panic/stop_cpu everywhere. The benefit is > having > only one place to fix over multiple one because very likely the > decision > is the

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Fri, 2018-05-11 at 11:54 +0100, Julien Grall wrote: > On 11/05/18 11:41, Mirela Simonovic wrote: > "We should really avoid to use panic(...) if this is something the > system can survive. In that specific case, it would only affect the > current CPU. So it would be better to return an error

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On 11/05/18 13:20, Mirela Simonovic wrote: Hi, On Fri, May 11, 2018 at 2:07 PM, Mirela Simonovic wrote: On Fri, May 11, 2018 at 12:54 PM, Julien Grall wrote: On 11/05/18 11:41, Mirela Simonovic wrote: On Thu, May 10, 2018 at 6:24 PM,

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On Fri, 2018-05-11 at 12:41 +0200, Mirela Simonovic wrote: > Hi Dario, > Hi, > On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli > wrote: > > I may very well be missing or misunderstanding something, but I > > continue to think that the problem here is that CPU_STARTING can't,

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

Hi, On Fri, May 11, 2018 at 2:07 PM, Mirela Simonovic wrote: > Hi Julien, > > On Fri, May 11, 2018 at 12:54 PM, Julien Grall wrote: >> >> >> On 11/05/18 11:41, Mirela Simonovic wrote: >>> >>> Hi Dario, >>> >>> On Thu, May 10, 2018 at 6:24 PM,

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

Hi Julien, On Fri, May 11, 2018 at 12:54 PM, Julien Grall wrote: > > > On 11/05/18 11:41, Mirela Simonovic wrote: >> >> Hi Dario, >> >> On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli >> wrote: >>> >>> On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic

[Xen-devel] [PATCH v1 1/2] x86/mm: Add mem access rights to NPT

From: Isaila Alexandru This patch adds access rights for the NPT pages. The access rights are saved in bits 59:56 of pte that are manipulated through p2m_set_access() and p2m_get_access() functions. The patch follows the ept logic. Note: It was tested with xen-access

[Xen-devel] [PATCH v1 2/2] hvm/svm: Enable EMUL_UNIMPLEMENTED events on svm

Signed-off-by: Alexandru Isaila --- xen/include/asm-x86/monitor.h | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h index c5a86d1..7ef2aa2 100644 ---

[Xen-devel] [PATCH 10/10] x86/spec_ctrl: Elide MSR_SPEC_CTRL handling in idle context when possible

If Xen is virtualising MSR_SPEC_CTRL handling for guests, but using 0 as its own MSR_SPEC_CTRL value, spec_ctrl_{enter,exit}_idle() need not write to the MSR. Requested-by: Jan Beulich Signed-off-by: Andrew Cooper --- CC: Jan Beulich

[Xen-devel] [GIT PULL] xen: fix for 4.17-rc5

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.17-rc5-tag xen: fix for 4.17-rc5 It contains one fix for the kernel running as a fully virtualized guest using PV drivers on old Xen hypervisor versions. Thanks. Juergen

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

On 11/05/18 11:41, Mirela Simonovic wrote: Hi Dario, On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli wrote: On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote: Regardless of the fact that the notifier returns an error or not, I believe it would be good and safe

[Xen-devel] [xen-4.6-testing test] 122657: regressions - FAIL

flight 122657 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122657/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122461

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

Hi Dario, On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli wrote: > On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote: >> Regardless of the fact that the notifier returns an error or not, I >> believe it would be good and safe to set priority and document that >>

[Xen-devel] [PATCH 07/10] x86/spec_ctrl: Explicitly set Xen's default MSR_SPEC_CTRL value

With the impending ability to disable MSR_SPEC_CTRL handling on a per-guest-type basis, the first exit-from-guest may not have the side effect of loading Xen's choice of value. Explicitly set Xen's default during the BSP and AP boot paths. For the BSP however, delay setting a non-zero

[Xen-devel] [PATCH 09/10] x86/spec_ctrl: Introduce a new `spec-ctrl=` command line argument to replace `bti=`

In hindsight, the options for `bti=` aren't as flexible or useful as expected (including several options which don't appear to behave as intended). Changing the behaviour of an existing option is problematic for compatibility, so introduce a new `spec-ctrl=` in the hopes that we can do better.

[Xen-devel] [PATCH 08/10] x86/cpuid: Improvements to guest policies for speculative sidechannel features

If Xen isn't virtualising MSR_SPEC_CTRL for guests, IBRSB shouldn't be advertised. It is not currently possible to express this via the existing command line options, but such an ability will be introduced. Another useful option in some usecases is to offer IBPB without IBRS. When a guest

[Xen-devel] [PATCH 02/10] x86/spec_ctrl: Express Xen's choice of MSR_SPEC_CTRL value as a variable

At the moment, we have two different encodings of Xen's MSR_SPEC_CTRL value, which is a side effect of how the Spectre series developed. One encoding is via an alias with the bottom bit of bti_ist_info, and can encode IBRS or not, but not other configuraitons such as STIBP. Break Xen's value out

[Xen-devel] [PATCH 01/10] x86/spec_ctrl: Read MSR_ARCH_CAPABILITIES only once

Make it available from the beginning of init_speculation_mitigations(), and pass it into appropriate functions. Fix an RSBA typo while moving the affected comment. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu

[Xen-devel] [PATCH 06/10] x86/spec_ctrl: Split X86_FEATURE_SC_MSR into PV and HVM variants

In order to separately control whether MSR_SPEC_CTRL is virtualised for PV and HVM guests, split the feature used to control runtime alternatives into two. Xen will use MSR_SPEC_CTRL itself if either of these features are active. Signed-off-by: Andrew Cooper --- CC:

[Xen-devel] [PATCH for-4.11 00/10] x86: Improvements and fixes to Spectre handling

In hindsight, the end result of the Spectre mitigations aren't as great as I'd hoped, and have several inefficiencies. Also, the `bti=` command line option isn't as flexible as intended. This series does four things: 1) Some internal cleanup, for clarity and to help the other features 2)

[Xen-devel] [PATCH 04/10] x86/spec_ctrl: Fold the XEN_IBRS_{SET, CLEAR} ALTERNATIVES together

Currently, the SPEC_CTRL_{ENTRY,EXIT}_* macros encode Xen's choice of MSR_SPEC_CTRL as an immediate constant, and chooses between IBRS or not by doubling up the entire alternative block. There is now a variable holding Xen's choice of value, so use that and simplify the alternatives.

[Xen-devel] [PATCH 05/10] x86/spec_ctrl: Rename bits of infrastructure to avoid NATIVE and VMEXIT

In hindsight, using NATIVE and VMEXIT as naming terminology was not clever. A future change wants to split SPEC_CTRL_EXIT_TO_GUEST into PV and HVM specific implementations, and using VMEXIT as a term is completely wrong. Take the opportunity to fix some stale documentation in spec_ctrl_asm.h.

[Xen-devel] [PATCH 03/10] x86/spec_ctrl: Merge bti_ist_info and use_shadow_spec_ctrl into spec_ctrl_flags

All 3 bits of information here are control flags for the entry/exit code behaviour. Treat them as such, rather than having two different variables. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau

[Xen-devel] Xen Security Advisory 262 (CVE-2018-10981) - qemu may drive Xen into unbounded loop

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-10981 / XSA-262 version 3 qemu may drive Xen into unbounded loop UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION =

[Xen-devel] Xen Security Advisory 261 (CVE-2018-10982) - x86 vHPET interrupt injection errors

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-10982 / XSA-261 version 3 x86 vHPET interrupt injection errors UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION =

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

flight 122647 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/122647/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 118324

[Xen-devel] [distros-debian-jessie test] 74707: tolerable FAIL

flight 74707 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74707/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74672 baseline version:

Re: [Xen-devel] [PATCH v2 2/3] xen/store: do not store local values in xen_start_info

On 09/05/18 12:21, Roger Pau Monne wrote: > There's no need to store the xenstore page or event channel in > xen_start_info if they are locally initialized. > > This also fixes PVH local xenstore initialization due to the lack of > xen_start_info in that case. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On 09/05/18 17:11, Roger Pau Monné wrote: > On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote: >> On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote: >>> On 09/05/18 11:21, Roger Pau Monne wrote: >>> I'm not sure that setting the default MTRR type is going to be a >>>