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

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

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

flight 118643 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/118643/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118630 Tests which did

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On Wed, 7 Feb 2018 13:01:08 + Igor Druzhinin wrote: >So far the issue confirmed: >Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one >that it was tested on), Intel S2600XX, etc. > >Also see: >https://bugs.xenserver.org/browse/XSO-774 > >Well,

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

flight 118647 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118647/ 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] [linux-next test] 118636: regressions - trouble: broken/fail/pass

flight 118636 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/118636/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 broken test-amd64-i386-freebsd10-amd64 4

[Xen-devel] [PATCH] libxl: set channel devid when not provided by application

Applications like libvirt may not populate a device devid field, delegating that to libxl. If needed, the application can later retrieve the libxl-produced devid. Indeed most devices are handled this way in libvirt, channel devices included. This works well when only one channel device is

Re: [Xen-devel] [PATCH] x86/xen: Calculate __max_logical_packages on PV domains

On 02/07/2018 06:49 PM, Prarit Bhargava wrote: The kernel panics on PV domains because native_smp_cpus_done() is only called for HVM domains. Calculate __max_logical_packages for PV domains. Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate") Signed-off-by: Prarit

[Xen-devel] [PATCH] x86/xen: Calculate __max_logical_packages on PV domains

The kernel panics on PV domains because native_smp_cpus_done() is only called for HVM domains. Calculate __max_logical_packages for PV domains. Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate") Signed-off-by: Prarit Bhargava Tested-and-reported-by:

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

flight 118665 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118665/ 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 2/2] xen: xenbus: WARN_ON XS_TRANSACTION_{START, END} misuse

As the previous commit shows it's quite easy to confuse the transaction reference counting by ending a transaction twice. So at least try to detect and report it. Signed-off-by: Simon Gaiser --- drivers/xen/xenbus/xenbus_xs.c | 9 + 1 file changed, 9

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

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 XS_TRANSACTION_END xenbus_dev_request_and_reply() would not decrement

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

If Andy wants to use his version of this, that's fine also. This is just a newer version based on Jan's input. v1 -> v2 Got rid of "== X"s Added an assert and got rid of a check in an if -- Brian Woods ___ Xen-devel mailing list

[Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set. Reported-by: Andrew Cooper Signed-off-by: Brian Woods --- xen/arch/x86/hvm/svm/svm.c | 71 + xen/arch/x86/hvm/svm/vmcb.c | 17

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

flight 118660 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118660/ 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] update on the status of SP2 mitigations for Xen on Arm

Hi all, This is the latest status of the SP2 mitigations for Xen on Arm. Please note that arm32 and arm64 require different mitigations. I have just backported the arm32 mitigation to 4.10, 4.9, 4.8 and 4.7: - 4.10 bbd093c xen/arm32: entry: Document the purpose of r11 in the traps handler

Re: [Xen-devel] [PATCH v2 1/7] x86: slightly reduce Meltdown band-aid overhead

On 07/02/18 16:12, Jan Beulich wrote: > I'm not sure why I didn't do this right away: By avoiding the use of > global PTEs in the cloned directmap, there's no need to fiddle with > CR4.PGE on any of the entry paths. Only the exit paths need to flush > global mappings. > > The reduced flushing,

Re: [Xen-devel] [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate

On 02/07/2018 02:26 PM, Simon Gaiser wrote: > Prarit Bhargava: >> On 02/07/2018 01:44 PM, Simon Gaiser wrote: >>> This breaks booting as Xen PV domain for me. The problem seems to be >>> that native_smp_cpus_done() is never called on a PV domain. So >>> __max_logical_packages is uninitialized

Re: [Xen-devel] [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate

Prarit Bhargava: > On 02/07/2018 01:44 PM, Simon Gaiser wrote: >> Prarit Bhargava: >>> A system booted with a small number of cores enabled per package >>> panics because the estimate of __max_logical_packages is too low. >>> This occurs when the total number of active cores across all packages

Re: [Xen-devel] [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate

On 02/07/2018 01:44 PM, Simon Gaiser wrote: > Prarit Bhargava: >> A system booted with a small number of cores enabled per package >> panics because the estimate of __max_logical_packages is too low. >> This occurs when the total number of active cores across all packages >> is less than the

[Xen-devel] [xen-unstable test] 118633: trouble: broken/fail/pass

flight 118633 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/118633/ Failures and problems with tests :-( 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] [v6, 3/3] x86/smpboot: Fix __max_logical_packages estimate

Prarit Bhargava: > A system booted with a small number of cores enabled per package > panics because the estimate of __max_logical_packages is too low. > This occurs when the total number of active cores across all packages > is less than the maximum core count for a single package. > > ie) On a

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

On 02/07/2018 07:01 PM, Jan Beulich wrote: On 02.02.18 at 09:14, wrote: >> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer) >> } >> } >> >> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */ >> +{ >> +

Re: [Xen-devel] [PATCH 1/2] ocaml/xb: update xb.mli in accordance with df1e4c6e7f8

> On 7. Feb 2018, at 17:09, Wei Liu wrote: > > Signed-off-by: Wei Liu > --- > tools/ocaml/libs/xb/xb.mli | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli > index

Re: [Xen-devel] [PATCH 2/2] ocaml/libs/xb: don't generate *.mli automatically

> On 7. Feb 2018, at 17:09, Wei Liu wrote: > > To stay in line with other parts of the ocaml code base. > > This requires committing a bunch of mli files in tree. > > Signed-off-by: Wei Liu > --- > tools/ocaml/libs/xb/Makefile| 4 >

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

flight 118650 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118650/ 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] stubdom: install firmware files as data

On Wed, Feb 07, 2018 at 04:11:17PM +0100, Olaf Hering wrote: > Remove the executable bits of vtpm files by using _DATA instead of _PROG. > > Signed-off-by: Olaf Hering Acked-by: Wei Liu ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 07/02/18 15:06, Jan Beulich wrote: On 07.02.18 at 14:24, wrote: >> On 07/02/18 13:08, Jan Beulich wrote: >> On 07.02.18 at 14:01, wrote: So far the issue confirmed: Dell PowerEdge R740, Huawei systems based on Xeon Gold

[Xen-devel] [PATCH 0/2] Ocaml: misc fixes

Wei Liu (2): ocaml/xb: update xb.mli in accordance with df1e4c6e7f8 ocaml/libs/xb: don't generate *.mli automatically tools/ocaml/libs/xb/Makefile| 4 tools/ocaml/libs/xb/op.mli | 29 + tools/ocaml/libs/xb/packet.mli | 13 +

[Xen-devel] [PATCH 2/2] ocaml/libs/xb: don't generate *.mli automatically

To stay in line with other parts of the ocaml code base. This requires committing a bunch of mli files in tree. Signed-off-by: Wei Liu --- tools/ocaml/libs/xb/Makefile| 4 tools/ocaml/libs/xb/op.mli | 29 +

[Xen-devel] [PATCH 1/2] ocaml/xb: update xb.mli in accordance with df1e4c6e7f8

Signed-off-by: Wei Liu --- tools/ocaml/libs/xb/xb.mli | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli index b4d705201f..95d1c6f840 100644 --- a/tools/ocaml/libs/xb/xb.mli +++

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

>>> On 02.02.18 at 09:14, wrote: > @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer) > } > } > > +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */ > +{ > +noflush = !!(value & X86_CR3_NOFLUSH);

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

On 07/02/18 16:27, Zhongze Liu wrote: Hi Wei and Julien, Hi, 2018-02-07 2:06 GMT+08:00 Wei Liu : On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote: if (libxl__device_pci_destroy_all(gc, domid) < 0) LOGD(ERROR, domid, "Pci shutdown failed");

Re: [Xen-devel] [PATCH 3/4] firmware/shim: better filtering of intermediate files during Xen tree setup

>>> On 07.02.18 at 17:12, wrote: > On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote: >> I have no idea what *.1 is meant to cover. Instead also exclude >> preprocessed and non-source assembly files. > > Oh, I guess that answers my question in 2/4 then. I don't

Re: [Xen-devel] [PATCH 2/4] firmware/shim: better filtering of dependency files during Xen tree setup

>>> On 07.02.18 at 17:05, wrote: > On Wed, Feb 07, 2018 at 08:07:40AM -0700, Jan Beulich wrote: >> I have no idea what *.d1 is supposed to refer to - we only have .*.d >> and .*.d2 files (note also the leading dot). >> >> Signed-off-by: Jan Beulich >>

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

Hi Wei and Julien, 2018-02-07 2:06 GMT+08:00 Wei Liu : > On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote: >> > if (libxl__device_pci_destroy_all(gc, domid) < 0) >> > LOGD(ERROR, domid, "Pci shutdown failed"); >> > rc =

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

On Wed, Feb 07, 2018 at 08:37:13AM -0700, Jan Beulich wrote: > >>> On 07.02.18 at 11:53, wrote: > > docs/misc/coverage.markdown | 2 +- > > xen/Kconfig.debug| 6 +++--- > > xen/Rules.mk | 9 +++-- > > xen/arch/x86/efi/Makefile| 2 +- > >

Re: [Xen-devel] [PATCH 4/4] firmware/shim: avoid mkdir error during Xen tree setup

On Wed, Feb 07, 2018 at 08:08:47AM -0700, Jan Beulich wrote: > "mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly > enough this doesn't cause the whole command (and hence the build to > fail), despite the "set -e" now covering the entire set of commands - > perhaps a quirk of

Re: [Xen-devel] [PATCH 3/4] firmware/shim: better filtering of intermediate files during Xen tree setup

On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote: > I have no idea what *.1 is meant to cover. Instead also exclude > preprocessed and non-source assembly files. Oh, I guess that answers my question in 2/4 then. I don't seem to have neither .i or .a files, but certainly .s should be

[Xen-devel] [PATCH v2 6/7] x86: disable XPTI when RDCL_NO

Use the respective ARCH_CAPABILITIES MSR bit, but don't expose the MSR to guests yet. Signed-off-by: Jan Beulich --- v2: New. --- a/tools/libxl/libxl_cpuid.c +++ b/tools/libxl/libxl_cpuid.c @@ -204,6 +204,7 @@ int libxl_cpuid_parse_config(libxl_cpuid

[Xen-devel] [PATCH v2 5/7] x86: avoid double CR3 reload when switching to guest user mode

When XPTI is active, the CR3 load in restore_all_guest is sufficient when switching to user mode, improving in particular system call and page fault exit paths for the guest. Signed-off-by: Jan Beulich --- v2: Add ASSERT(!in_irq()). --- a/xen/arch/x86/pv/domain.c +++

[Xen-devel] [PATCH v2 4/7] x86: NOP out most XPTI entry/exit code when it's not in use

Introduce a synthetic feature flag to use alternative instruction patching to NOP out all code on entry/exit paths other than those involved in NMI/#MC handling (the patching logic can't properly handle those paths yet). Having NOPs here is generally better than using conditional branches. Also

[Xen-devel] [PATCH v2 2/7] x86: remove CR reads from exit-to-guest path

CR3 is - during normal operation - only ever loaded from v->arch.cr3, so there's no need to read the actual control register. For CR4 we can generally use the cached value on all synchronous entry end exit paths. Drop the write_cr3 macro, as the two use sites are probably easier to follow without

[Xen-devel] [PATCH v2 1/7] x86: slightly reduce Meltdown band-aid overhead

I'm not sure why I didn't do this right away: By avoiding the use of global PTEs in the cloned directmap, there's no need to fiddle with CR4.PGE on any of the entry paths. Only the exit paths need to flush global mappings. The reduced flushing, however, implies that we now need to have interrupts

[Xen-devel] [PATCH v2 0/7] x86: Meltdown band-aid overhead reduction

1: slightly reduce Meltdown band-aid overhead 2: remove CR reads from exit-to-guest path 3: introduce altinstruction_nop assembler macro 4: NOP out most XPTI entry/exit code when it's not in use 5: avoid double CR3 reload when switching to guest user mode 6: disable XPTI when RDCL_NO 7: x86: log

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

>>> On 07.02.18 at 11:53, wrote: > docs/misc/coverage.markdown | 2 +- > xen/Kconfig.debug| 6 +++--- > xen/Rules.mk | 9 +++-- > xen/arch/x86/efi/Makefile| 2 +- > xen/common/Makefile | 2 +- > xen/common/coverage/Makefile | 5

[Xen-devel] Ping: [PATCH v2 0/3] XSA-248...251 follow-up

>>> On 20.12.17 at 10:37, wrote: > The parts of this series aren't really dependent upon one another, > they belong together solely because of their origin. > > 1: x86/shadow: widen reference count > 2: x86/mm: clean up SHARED_M2P{,_ENTRY} uses > 3: x86: use paging_mark_pfn_dirty() George, any

Re: [Xen-devel] qemu-xen fails to build in staging

On Wed, Feb 07, 2018 at 02:44:05PM +, Anthony PERARD wrote: > On Wed, Feb 07, 2018 at 01:40:04PM +0100, Olaf Hering wrote: > > Am Wed, 7 Feb 2018 11:13:22 +0100 > > schrieb Olaf Hering : > > > > > Yes, it looks like qemu has now submodules which are required for build. > > >

Re: [Xen-devel] [PATCH] x86/emul: Fix the decoding of segment overrides in 64bit mode

>>> On 07.02.18 at 15:41, wrote: > Explicit segment overides other than %fs and %gs are documented as ignored by > both Intel and AMD. > > In practice, this means that: > > * Explicit uses of %ss don't actually yield #SS[0] for non-canonical >memory references. >

[Xen-devel] [PATCH] stubdom: install firmware files as data

Remove the executable bits of vtpm files by using _DATA instead of _PROG. Signed-off-by: Olaf Hering --- stubdom/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/stubdom/Makefile b/stubdom/Makefile index f45eeabd8b..7cb62e6c36 100644 ---

[Xen-devel] [PATCH 4/4] firmware/shim: avoid mkdir error during Xen tree setup

"mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly enough this doesn't cause the whole command (and hence the build to fail), despite the "set -e" now covering the entire set of commands - perhaps a quirk of the relatively old bash I've seen this with (a few simple experiments

[Xen-devel] [PATCH 3/4] firmware/shim: better filtering of intermediate files during Xen tree setup

I have no idea what *.1 is meant to cover. Instead also exclude preprocessed and non-source assembly files. Signed-off-by: Jan Beulich --- unstable.orig/tools/firmware/xen-dir/Makefile 2018-02-07 15:30:24.038600788 +0100 +++ unstable/tools/firmware/xen-dir/Makefile

[Xen-devel] [PATCH 2/4] firmware/shim: better filtering of dependency files during Xen tree setup

I have no idea what *.d1 is supposed to refer to - we only have .*.d and .*.d2 files (note also the leading dot). Signed-off-by: Jan Beulich --- a/tools/firmware/xen-dir/Makefile +++ b/tools/firmware/xen-dir/Makefile @@ -26,7 +26,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES)

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

>>> On 07.02.18 at 14:24, wrote: > On 07/02/18 13:08, Jan Beulich wrote: > On 07.02.18 at 14:01, wrote: >>> So far the issue confirmed: >>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one >>> that it was tested on),

[Xen-devel] [PATCH 1/4] firmware/shim: correctly handle errors during Xen tree setup

"set -e" on a separate Makefile line is meaningless. Glue together all the lines that this is supposed to cover. Signed-off-by: Jan Beulich --- a/tools/firmware/xen-dir/Makefile +++ b/tools/firmware/xen-dir/Makefile @@ -16,18 +16,18 @@ DEP_FILES=$(foreach i, $(LINK_FILES), $(

[Xen-devel] [PATCH 0/4] firmware/shim: fix Xen tree setup

This is a split of the RFC with the mkdir fix added, but with the symlink handling left off for now (I'll need some more time to properly deal with that without using -xtype, ideally treating absolute and relative ones differently). 1: correctly handle errors during Xen tree setup 2: better

Re: [Xen-devel] qemu-xen fails to build in staging

On Wed, Feb 07, 2018 at 01:40:04PM +0100, Olaf Hering wrote: > Am Wed, 7 Feb 2018 11:13:22 +0100 > schrieb Olaf Hering : > > > Yes, it looks like qemu has now submodules which are required for build. > > How is the required state of the submodules tracked? Hi, QEMU have now a

[Xen-devel] [PATCH] x86/emul: Fix the decoding of segment overrides in 64bit mode

Explicit segment overides other than %fs and %gs are documented as ignored by both Intel and AMD. In practice, this means that: * Explicit uses of %ss don't actually yield #SS[0] for non-canonical memory references. * Explicit uses of %{e,c,d}s don't override %rbp/%rsp-based memory

Re: [Xen-devel] [PATCH RFC 7/8] xen-blkback: frontend feature control

On 02/07/2018 12:08 PM, Roger Pau Monné wrote: > On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote: >> Toolstack may write values to the "require" subdirectory in the >> backend main directory (e.g. backend/vbd/X/Y/). Read these values >> and use them when announcing those to the

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 07/02/18 13:08, Jan Beulich wrote: On 07.02.18 at 14:01, wrote: >> So far the issue confirmed: >> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one >> that it was tested on), Intel S2600XX, etc. >> >> Also see: >>

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

flight 118631 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118631/ 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 5/7] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

Hi, On 6 February 2018 at 20:12, Julien Grall wrote: > On 02/06/2018 04:23 PM, Volodymyr Babchuk wrote: >> >> Hi, > > > Hi, > >> On 5 February 2018 at 15:20, Julien Grall wrote: >>> >>> SMCCC 1.1 offers firmware-based CPU workarounds. In particular,

Re: [Xen-devel] [PATCH 7/7] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

Hi Julien, On 6 February 2018 at 20:33, Julien Grall wrote: > Hi, > > On 02/06/2018 04:36 PM, Volodymyr Babchuk wrote: >> >> On 5 February 2018 at 15:20, Julien Grall wrote: >>> >>> The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for

Re: [Xen-devel] [PATCH 4/7] xen/arm: vsmc: Implement SMCCC 1.1

Hi Julien, On 6 February 2018 at 20:04, Julien Grall wrote: > Hi, > > On 02/06/2018 04:18 PM, Volodymyr Babchuk wrote: >> >> On 5 February 2018 at 15:20, Julien Grall wrote: >>> >>> The new SMC Calling Convention (v1.1) allows for a reduced overhead

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 07/02/18 13:08, Jan Beulich wrote: On 07.02.18 at 14:01, wrote: >> So far the issue confirmed: >> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one >> that it was tested on), Intel S2600XX, etc. >> >> Also see: >>

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

>>> On 07.02.18 at 14:01, wrote: > So far the issue confirmed: > Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one > that it was tested on), Intel S2600XX, etc. > > Also see: > https://bugs.xenserver.org/browse/XSO-774 > > Well, no-watchdog is what

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

On 07/02/18 09:13, Jan Beulich wrote: On 06.02.18 at 22:51, wrote: >> The problem with a quirk/commandline parameter is that the issue is >> reported for a wide variety of systems and, as it looks like, depends on >> the default BIOS setup - means it's hard to

[Xen-devel] [libvirt test] 118632: tolerable all pass - PUSHED

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

Re: [Xen-devel] qemu-xen fails to build in staging

>>> On 07.02.18 at 13:40, wrote: > Am Wed, 7 Feb 2018 11:13:22 +0100 > schrieb Olaf Hering : > >> Yes, it looks like qemu has now submodules which are required for build. > > How is the required state of the submodules tracked? When I did a local > build I got

Re: [Xen-devel] qemu-xen fails to build in staging

Am Wed, 7 Feb 2018 11:13:22 +0100 schrieb Olaf Hering : > Yes, it looks like qemu has now submodules which are required for build. How is the required state of the submodules tracked? When I did a local build I got 10739aa from qemu.org, and building xen.git#staging succeeds.

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

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

Re: [Xen-devel] Problem with IOMEM and domain reboot

On 02/06/2018 02:52 PM, Wei Liu wrote: On Tue, Feb 06, 2018 at 02:44:56PM +0200, Oleksandr Andrushchenko wrote: From aa1f20af73a5a3c8f2c904b857a79334d18d41ff Mon Sep 17 00:00:00 2001 From: Oleksandr Andrushchenko Date: Wed, 20 Dec 2017 17:51:18 +0200

Re: [Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters

On 02/06/2018 05:12 PM, Wei Liu wrote: > (Three months after you sent this, sorry...) > > On Mon, Nov 06, 2017 at 12:33:06PM +, Joao Martins wrote: >> On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote: -Original Message- From: Joao Martins

Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

On 02/07/2018 11:16 AM, Roger Pau Monné wrote: > On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote: >> Hey folks, >> >> Presented herewith is an attempt to implement PV backends feature control >> as discussed in the list >>

Re: [Xen-devel] [PATCH RFC 7/8] xen-blkback: frontend feature control

On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote: > Toolstack may write values to the "require" subdirectory in the > backend main directory (e.g. backend/vbd/X/Y/). Read these values > and use them when announcing those to the frontend. When backend > scans frontend features the

Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

On 02/07/2018 11:30 AM, Roger Pau Monné wrote: > On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote: >> On 07/02/18 12:16, Roger Pau Monné wrote: >>> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote: * Toolstack constructs a key value store of features, and user

Re: [Xen-devel] [PATCH RFC 1/8] public/io/blkif: add directory for backend parameters

On Thu, Nov 02, 2017 at 06:06:09PM +, Joao Martins wrote: > The proposed directory provides a mechanism for tools to control the > maximum feature set of the device being provisioned by backends. > Examples include max ring page order, persistent grants, number of > queues etc. > >

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

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

Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

On 07/02/18 12:16, Roger Pau Monné wrote: > On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote: >> Hey folks, >> >> Presented herewith is an attempt to implement PV backends feature control >> as discussed in the list >>

Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote: > Hey folks, > > Presented herewith is an attempt to implement PV backends feature control > as discussed in the list > (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html) > > Given that this a simple proposal hence

[Xen-devel] [PATCH v4 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

Re: [Xen-devel] [PATCH v3] x86/boot: Make alternative patching NMI-safe

>>> On 06.02.18 at 12:09, wrote: > During patching, there is a very slim risk that an NMI or MCE interrupt in the > middle of altering the code in the NMI/MCE paths, in which case bad things > will happen. > > The NMI risk can be eliminated by running the patching loop

Re: [Xen-devel] [PATCH] docs: clearify symlink usage in xen-pv-channel

On Wed, Feb 07, 2018 at 09:45:53AM +0100, Olaf Hering wrote: > The previous version simply states that a symlink has to be created > without telling where the symlink should point to. > > Signed-off-by: Olaf Hering Acked-by: Wei Liu

Re: [Xen-devel] [PATCH] docs: fix kernel config option in xen-pv-channel

On Wed, Feb 07, 2018 at 09:30:57AM +0100, Olaf Hering wrote: > HVC is shown underlined, the underscores are missing. > Fix it by using underscores. > Remove stale I. > > Signed-off-by: Olaf Hering Acked-by: Wei Liu

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

On Tue, Feb 06, 2018 at 09:56:14PM +, Michael Young wrote: > On Tue, 6 Feb 2018, Wei Liu wrote: > > > On Tue, Jan 30, 2018 at 10:55:47PM +, Michael Young wrote: > > > Xen built with ocaml 4.06 gives errors such as > > > Error: This expression has type bytes but an expression was > > >

[Xen-devel] [xen-unstable-coverity test] 118635: all pass - PUSHED

flight 118635 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/118635/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58 baseline version: xen

Re: [Xen-devel] qemu-xen fails to build in staging

Am Wed, 07 Feb 2018 02:56:55 -0700 schrieb "Jan Beulich" : > I think I had seen this too, and only then I realized that now I need > to set up the respective submodule in the qemu tree. Yes, it looks like qemu has now submodules which are required for build. Neither configure

Re: [Xen-devel] qemu-xen fails to build in staging

>>> On 07.02.18 at 09:18, wrote: > With current staging, qemu-xen fails to build. It looks like a ordering > issue, I assume ui/input-keymap-linux-to-qcode.c is a generated file. > It is (as always) a fresh clean checkout in a clean chroot. I think I had seen this too, and only

Re: [Xen-devel] [PATCH 1/3] Make credit2 the default scheduler

On 02/06/2018 10:39 PM, Dario Faggioli wrote: > On Tue, 2018-02-06 at 17:02 +, George Dunlap wrote: >> On 02/06/2018 06:18 AM, Juergen Gross wrote: >>> On 05/02/18 17:53, Dario Faggioli wrote: Considering we're releasing in June, but freezing in March, do we think it is

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

>>> On 06.02.18 at 22:51, wrote: > The problem with a quirk/commandline parameter is that the issue is > reported for a wide variety of systems and, as it looks like, depends on > the default BIOS setup - means it's hard to identify particular > machines. We should

[Xen-devel] [PATCH] docs: clearify symlink usage in xen-pv-channel

The previous version simply states that a symlink has to be created without telling where the symlink should point to. Signed-off-by: Olaf Hering --- docs/man/xen-pv-channel.pod.7 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/man/xen-pv-channel.pod.7

[Xen-devel] [PATCH] docs: fix kernel config option in xen-pv-channel

HVC is shown underlined, the underscores are missing. Fix it by using underscores. Remove stale I. Signed-off-by: Olaf Hering --- docs/man/xen-pv-channel.pod.7 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/man/xen-pv-channel.pod.7

[Xen-devel] qemu-xen fails to build in staging

With current staging, qemu-xen fails to build. It looks like a ordering issue, I assume ui/input-keymap-linux-to-qcode.c is a generated file. It is (as always) a fresh clean checkout in a clean chroot. [ 505s]