date:20191113

Re: [Xen-devel] [PATCH 3/3] xen/mcelog: also allow building for 32-bit kernels

2019-11-13 Thread Jürgen Groß


On 13.11.19 14:47, Jan Beulich wrote:

On 13.11.2019 01:15, Boris Ostrovsky wrote:

On 11/11/19 9:46 AM, Jan Beulich wrote:

There's no apparent reason why it can be used on 64-bit only.

Signed-off-by: Jan Beulich 

--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR
  
  config XEN_MCE_LOG

bool "Xen platform mcelog"
-   depends on XEN_DOM0 && X86_64 && X86_MCE
+   depends on XEN_DOM0 && X86 && X86_MCE


Can we have X86_MCE without X86?


I don't think we can. Is this a request to drop the middle
operand altogether?


No need to resend the series. I can make this change while committing.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] xen/sched: Render sibling/core masks with %pbl to improve 'r' debugkey

2019-11-13 Thread Jürgen Groß


On 13.11.19 19:36, Andrew Cooper wrote:

For system with large numbers of CPUs, the 'r' debugkey is unwieldy.  Sibling
and core masks are a single block of adjacent bits, so are vastly shorter to
render with %pbl.

Before:
   (XEN) CPU[00] nr_run=0, sort=157, 
sibling=,,,,,,,0003,
 core=,,,,,,,
   (XEN) CPU[01] nr_run=0, sort=13750, 
sibling=,,,,,,,0003,
 core=,,,,,,,
   (XEN) CPU[02] nr_run=0, sort=188, 
sibling=,,,,,,,000c,
 core=,,,,,,,
   (XEN) CPU[03] nr_run=0, sort=13730, 
sibling=,,,,,,,000c,
 core=,,,,,,,

After:
   (XEN) CPU[00] nr_run=0, sort=1169, sibling={0-1}, core={0-127}
   (XEN) CPU[01] nr_run=0, sort=2488, sibling={0-1}, core={0-127}
   (XEN) CPU[02] nr_run=0, sort=1210, sibling={2-3}, core={0-127}
   (XEN) CPU[03] nr_run=0, sort=2476, sibling={2-3}, core={0-127}

Signed-off-by: Andrew Cooper 


Reviewed-by: Juergen Gross 
Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen: make debugger support configurable

2019-11-13 Thread Jürgen Groß


On 13.11.19 18:26, Andrew Cooper wrote:

On 13/11/2019 16:22, Juergen Gross wrote:

Debugger support in the hypervisor is rarely used and it is opening a
way for dom0 to modify the running hypervisor by very easy means.

Add a Kconfig option to control support of gdbsx. Default is off.

Signed-off-by: Juergen Gross 
---
  xen/Kconfig.debug  |  4 
  xen/arch/x86/Kconfig   |  1 -
  xen/arch/x86/domctl.c  |  4 
  xen/common/Kconfig |  3 ---
  xen/common/domain.c|  2 +-
  xen/include/asm-x86/debugger.h | 30 ++
  xen/include/xen/sched.h|  4 
  7 files changed, 31 insertions(+), 17 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 22573e74db..84a6e1b8eb 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -13,9 +13,13 @@ config DEBUG
  
  if DEBUG || EXPERT = "y"
  
+config GDBSX

+   bool
+
  config CRASH_DEBUG
bool "Crash Debugging Support"
depends on X86
+   select GDBSX
---help---
  If you want to attach gdb to Xen to debug Xen if it crashes
  then say Y.


CRASH_DEBUG and GDBSX are unrelated.

The former is gdbstub over serial for Xen itself (which I've never seen
used, and therefore doubt functions), while the latter is a set of dom0
hypercalls used by the gdbsx utility.

I'm happy to make CONFIG_GDBSX more useful than it currently is, but I
don't think the two options want conflating.


Ah, okay.

Will send V2 with 2 patches: one for putting more code under
CONFIG_CRASH_DEBUG and one for introducing CONFIG_GDBSX.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

2019-11-13 Thread Julien Grall

On Tue, 12 Nov 2019, 11:45 Peng Fan,  wrote:

> Hi Julien,
>
> Inline marked with [Peng Fan]
>
> From: Julien Grall 
> Sent: 2019年11月9日 6:44
> To: Stefano Stabellini ; Andre Przywara <
> andre.przyw...@arm.com>
> Cc: Peng Fan ; Jürgen Groß ;
> julien.gr...@arm.com; xen-de...@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER
> range
>
> Hi,
>
> Sorry for the formatting.
> On Sat, 9 Nov 2019, 04:27 Stefano Stabellini,  sstabell...@kernel.org> wrote:
> On Thu, 7 Nov 2019, Peng Fan wrote:
> > The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
> >
> > Signed-off-by: Peng Fan 
>
> Reviewed-by: Stefano Stabellini 
>
> To be honest, I am not sure the code is correct. A read to those registers
> should tell you the list of interrupts active. As we always return 0, this
> will not return the correct state of the GIC.
>
> I know that returning the list of actives interrupts is complicated with
> the old vGIC, but I don't think silently ignoring it is a good idea.
>
> The question here is why the guest accessed those registers? What is it
> trying to figure out?
>
> [Peng Fan] I am running Linux 5.4 kernel dom0, gic_peek_irq triggers abort.
>

Do you have a call stack trace for this?

Cheers,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [xen-unstable test] 144067: regressions - FAIL

2019-11-13 Thread Jürgen Groß


On 14.11.19 00:06, osstest service owner wrote:

flight 144067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144067/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
  test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 
guest-start/debianhvm.repeat fail REGR. vs. 144042


qemu had a segfault. Could someone look at that, please?


  test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. 
vs. 144042


Seems to be the same issue as already seen on older Xen versions. Anyone
already at it?


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.11-testing test] 144073: regressions - FAIL

2019-11-13 Thread osstest service owner

flight 144073 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144073/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
144025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  74507046dbd2c5d2991eeabd1af39af0d6b29d70
baseline version:
 xen  006b2041242129896fbd30135b3dc6f575894a07

Last test of basis   144025  2019-11-11 17:36:00 Z2 days
Testing same since   144058  2019-11-12 18:05:56 Z1 days2 attempts

[Xen-devel] [PATCH V2] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit)

2019-11-13 Thread Julian Tuminaro

From: Julian Tuminaro and Jenish Rakholiya 

Current implementation of find_os is based on the hard-coded values for
different Windows version. It uses the value for get the address to
start looking for DOS header in the given specified range. However, this
is not scalable to all version of Windows as it will require us to keep
adding new entries and also due to KASLR, chances of not hitting the PE
header is significant. We implement a way for 64-bit systems to use IDT
entry to get a valid exception/interrupt handler and then move back into
the memory to find the valid DOS header. Since IDT entries are protected
by PatchGuard, we think our assumption that IDT entries will not be
corrupted is valid for our purpose. Once we have the image base, we
search for the DBGKD_GET_VERSION64 structure type in .data section to
get information required for handshake.

Currently, this is a work in progress feature and current patch only
supports the handshake and memory read/write on 64-bit systems.

NOTE: This is the Updated version of the previous patch submitted
NOTE: This has currently been only tested when debugging was not enabled
on the guest Windows.

Signed-off-by: Jenish Rakholiya 
Signed-off-by: Julian Tuminaro 
---
 tools/debugger/kdd/kdd.c | 392 ---
 1 file changed, 366 insertions(+), 26 deletions(-)

diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
index fb8c645355..6d3febefda 100644
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -51,6 +52,16 @@
 
 #include "kdd.h"
 
+/*
+ * TODO: kdd_os is a type which is used to represent os array. Adding a
+ * variable here would result in adding a new field to each element in array.
+ * However, since most of the fields are part of the same struct that we are
+ * trying to read from memory, we have added kddl to this structure. If
+ * required, we can possibly separate the kddl value to someplace else
+ *
+ * We also use kddl of size uint32_t which is actually used to represent the
+ * offset from image base rather than actual address
+ */
 /* Windows version details */
 typedef struct {
 uint32_t build; 
@@ -62,6 +73,7 @@ typedef struct {
 uint32_t version;   /* +-> NtBuildNumber */
 uint32_t modules;   /* +-> PsLoadedModuleList */
 uint32_t prcbs; /* +-> KiProcessorBlock */
+uint32_t kddl;  /* +-> KdDebuggerList */
 } kdd_os;
 
 /* State of the debugger stub */
@@ -85,6 +97,117 @@ typedef struct {
 kdd_os os; /* OS-specific magic numbers */
 } kdd_state;
 
+/**
+ * @brief Structure to represent DBGKD_GET_VERSION64
+ *
+ * reference: 
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdbgexts/ns-wdbgexts-_dbgkd_get_version64
+ */
+typedef struct {
+uint16_t MajorVersion; /* usually 0xf for free build */
+uint16_t MinorVersion;  /* build number of target OS */
+uint8_t ProtocolVersion; /* version of the debugger protocol */
+uint8_t KdSecondaryVersion;  /* secondary version number */
+uint16_t Flags;/* set of bit flags for the current debugging session */
+uint16_t MachineType;  /* type of the target's processor */
+uint8_t MaxPacketType; /* one plus the highest number for a debugger */
+ /* packet type recognized by the target */
+uint8_t MaxStateChagne;   /* one plus the highest number for a state */
+   /* change generated by the target */
+uint8_t MaxManipulate;   /* one more that the highest number, recognized */
+/* by the target, for a command to manipulate the target */
+uint8_t Simulation;/* indication if target is in simulated execution */
+uint16_t Unused[1];
+uint64_t KernBase;   /* base address of the kernel image */
+uint64_t PsLoadedModuleList; /* value of the kernel variable */
+   /* PsLoadedModuleList */
+uint64_t DebuggerDataList;   /* value of the kernel variable */
+  /* KdDebuggerDataBlock */
+} PACKED DBGKD_GET_VERSION64;
+
+/**
+ * @brief Structure to represent the section in PE headers
+ *
+ * reference: 
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#section-table-section-headers
+ */
+typedef struct {
+uint8_t Name[8];/* name of section */
+uint32_t VirtualSize;   /* total size of section in memory */
+uint32_t VirtualAddr;   /* offset from image base */
+uint32_t SizeOfRawData; /* size of section in for object files */
+uint32_t PointerToRawData;  /* file pointer to first page in COFF */
+uint32_t

Re: [Xen-devel] [RFC 2/7] WIP: Compilation with ARM DS-6 compiler

2019-11-13 Thread Julien Grall

On Thu, 14 Nov 2019, 02:15 Artem Mygaiev,  wrote:

> Hi Jan,
>
> Sorry for delayed reply
>
> On Thu, 2019-11-07 at 08:31 +0100, Jan Beulich wrote:
> > On 06.11.2019 23:08, Artem Mygaiev wrote:
> > > On Wed, Nov 6, 2019 at 4:28 PM Jan Beulich <
> > > jbeul...@suse.com
> > > > wrote:
> > > > On 06.11.2019 10:19, Andrii Anisov wrote:
> > > > > --- a/Config.mk
> > > > > +++ b/Config.mk
> > > > > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
> > > > >
> > > > >  $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
> > > > > statement)
> > > > >  $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
> > > > > +ifneq ($(armds),y)
> > > > >  $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
> > > > > +endif
> > > > >  $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
> > > > >
> > > > >  LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> > > >
> > > > ... this would be necessary.
> > >
> > > I am very sorry, this patch does not have a proper description
> > > indeed.
> > >
> > > For this particular change - arm clang does not undestand
> > > -Wno-unused-but-set-variable
> > > option at all, that is why it is under !$(armds)
> >
> > But avoiding to add options which the compiler doesn't understand
> > is the purpose of using cc-option-add, rather than blindly
> > adding
> > them to CFLAGS. What am I missing here?
>
> You are right, the script shall check the compiler option and avoid
> including it to CFLAGS. But armclang require '--target=...' to be
> specified in order to operate properly, and the proper fix shall be
> something like this (instead of 'ifneq' hack above):
>
> diff --git a/Config.mk b/Config.mk
> index 01487a7..abe8e44 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -107,7 +107,7 @@ cc-option = $(shell if test -z "`echo 'void*p=1;' | \
>  # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6)
>  cc-option-add = $(eval $(call cc-option-add-closure,$(1),$(2),$(3)))
>  define cc-option-add-closure
> -ifneq ($$(call cc-option,$$($(2)),$(3),n),n)
> +ifneq ($$(call cc-option,$$($(2) $(1)),$(3),n),n)
>  $(1) += $(3)
>  endif
>  endef
>
> so that CFLAGS that are already defined and include '--target=...'
> option from config/arm*.mk are passed to compiler to make it happy. I
> am not sure if this breaks anything else so decided to go with ugly
> 'ifneq' hack and check how this can be solved later on.
>

Why not including --target in CC variable as this was suggested for clang?

Cheers,

-- 
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files

2019-11-13 Thread Julien Grall

On Tue, 12 Nov 2019, 05:57 Stefano Stabellini, 
wrote:

> On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > From: Andrii Anisov 
> >
> > ARM Compiler 6 has a proven bug: it compiles data only C files with
> > SoftVFP attributes. This leads to a failed linkage afterwards with
> > an error:
> >
> > Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible with the image attributes.
> > ... A64 clashes with SoftVFP.
> >
> > The known workaround is introducing some code into the affected file,
> > e.g. an empty (non-static) function is enough.
>
> Oh man, this is truly horrible.
>
> If we really have to do this please:
>
> - use the same dummy function name in all files
> - the function should be static
> - hiding the function within a #ifdef ARMCC block
> - potentially hide the whole horrible hack behind a #define so that it
>   would become at the call site:
>
>  +ARMCC_DUMMY_FUNC_HACK()


The risk here is we may introduce new file in the future possibly in common
code with similar issues. So I would prefer if we can find an automatic way
to do this. Some ideas:
- Add the function at compile time (via makefile). This would be done
for all the files but that's should not be a major issues.
- Force disable softfvp either via command line, new line in the code
or rewriting the attribute of the object.

But before spending time trying to workaround a buggy compiler. What's the
plan with it? Is it going to be used in production or just a demo?

Cheers,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

2019-11-13 Thread osstest service owner

flight 144070 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144070/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 16 guest-localmigrate   fail REGR. vs. 144050
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 144050

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144050
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144050
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144050
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144050
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144050
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 qemuuaa464db69b40b4b695be31085e6d2f1e90956c89
baseline version:
 qemuu039e285e095c20a88e623b927654b161aaf9d914

Last test of basis   144050  2019-11-12 14:10:13 Z1 days
Testing same since   144070  2019-11-13 04:19:03 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Gerd Hoffmann 
  Laurent Vivier 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Thomas Huth 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64

Re: [Xen-devel] wall clock drift on Coffee Lake / C24x mainboard (HPET broken?), best practices

2019-11-13 Thread Andreas Kinzler


Hello All,

I came across the following: https://lkml.org/lkml/2019/8/29/536

Could that be the reason for the problem mentioned below? Xen is using 
HPET as clocksource on the platform/mainboard. Is there an (easy) way to 
verify if Xen uses PC10?


Regards Andreas

On 12.10.2019 20:47, Andreas Kinzler wrote:

Hello all, hello Paul,

On a certain new mainboard with chipset C242 and Intel Xeon E-2136 I 
notice a severe clock drift. This is from dom0:


# uptime
 20:13:52 up 81 days,  1:41,  1 user,  load average: 0.00, 0.00, 0.00
# hwclock
2019-10-12 20:27:37.204966+02:00
# date
Sat Oct 12 20:07:19 CEST 2019

Kernel is 4.13.16 vanilla, Xen 4.10.2

So after 81 days uptime there is a difference of over 20 minutes 
between "date" and "hwclock". I operate many Xen servers and have 
never seen such a great drift except on this type of mainboard. What 
could be the reason?


In general, what is the current best practice for NTP sync? Run it in 
dom0? In domU? Both? How does the domU type (Linux HVM/PVM/PVH or 
Windows HVM with WinPV drivers) make a difference?


Regards Andreas


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

2019-11-13 Thread osstest service owner

flight 144067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144067/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 
guest-start/debianhvm.repeat fail REGR. vs. 144042
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
144042

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 144042

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144042
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144042
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144042
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144042
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144042
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144042
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  8c4330818f6ee70cbf7428a40a28a73df1272d10
baseline version:
 xen  a458d3bd0d2585275c128556ec0cbd818c6a7b0d

Last test of basis   144042  2019-11-12 09:07:51 Z1 days
Testing same since   144067  2019-11-13 02:19:05 Z0 days

Re: [Xen-devel] [PATCH 08/24] golang/xenlight: define Mac builtin type

2019-11-13 Thread Nick Rosbrook

> What's the point of this?
>
> I realize it's slightly annoying to have to type `mac[0], mac[1], ...`,
> but I'd rather do that once than make the runtime copy everything over
> into a slice of interfaces every String() call.

As I think you realized by looking at subsequent patches, this is to
get around the fact that "an array of an interface type != an array of
type that implements that interface." Since this is a small array, I'm
fine with explicitly passing each element of the array to fmt.Sprintf.

> Also, I guess the format should be "%02x".

Yeah, thanks.

> Conversely, shouldn't this be a value receiver, since we're don't want
> this function to change the contents of mac?

Conventionally receivers are kept consistent between methods of a
type, unless it's implementing some interface like Stringer. And, it's
consistent with the other toC functions which are defined with
pointers in the generated functions since there are some large
structs.

But, yes this could just be a value receiver. I don't have a strong
opinion to keep it as is, so I'll change it.

-NR

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v4 2/3] x86/passthrough: fix migration of MSI when using posted interrupts

2019-11-13 Thread Joe Jin

Ran same test and did not hit the issue.

Tested-by: Joe Jin 

On 11/13/19 7:59 AM, Roger Pau Monne wrote:
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly injected at a later point when the MSI
> fields are already updated.
> 
> The usage of a fixed vCPU in lowest priority mode when using VT-d
> posted interrupts is also removed, and as a result VT-d posted
> interrupts are not used together with lowest priority mode and
> multiple destinations. That forces vlapic_lowest_prio to be called in
> order to select the destination vCPU during interrupt dispatch.
> 
> Note that PIRR is synced to IRR both in pt_irq_destroy_bind and
> pt_irq_create_bind when the interrupt delivery data is being updated.
> 
> Reported-by: Joe Jin 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Joe Jin 
> Cc: Juergen Gross 
> ---
> Changes since v3:
>  - In multi-destination mode make sure all destination vCPUs have PIR
>synced to IRR by using a bitmap.
>  - Drop the bogus selection of a fixed vCPU when using lowest priority
>mode.
> 
> Changes since v2:
>  - Also sync PIRR with IRR when using CPU posted interrupts.
>  - Force the selection of a specific vCPU when using posted interrupts
>for multi-dest.
>  - Change vmsi_deliver_pirq to honor dest_vcpu_id.
> 
> Changes since v1:
>  - Store the vcpu id also in multi-dest mode if the interrupt is bound
>to a vcpu for posted delivery.
>  - s/#if/#ifdef/.
> ---
>  xen/arch/x86/hvm/hvm.c   |  31 
>  xen/arch/x86/hvm/vlapic.c|  19 +
>  xen/arch/x86/hvm/vmsi.c  |  23 --
>  xen/drivers/passthrough/io.c | 118 ++-
>  xen/include/asm-x86/hvm/hvm.h|   5 +-
>  xen/include/asm-x86/hvm/vlapic.h |   3 +
>  6 files changed, 110 insertions(+), 89 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 06a7b40107..0e3379fa6f 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -43,6 +43,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -5266,6 +5267,36 @@ void hvm_set_segment_register(struct vcpu *v, enum 
> x86_segment seg,
>  alternative_vcall(hvm_funcs.set_segment_register, v, seg, reg);
>  }
>  
> +int hvm_intr_get_dests(struct domain *d, uint8_t dest, uint8_t dest_mode,
> +   uint8_t delivery_mode, unsigned long *vcpus)
> +{
> +struct vcpu *v;
> +
> +switch ( delivery_mode )
> +{
> +case dest_LowestPrio:
> +/*
> + * Get all the possible destinations, but note that lowest priority
> + * mode is only going to inject the interrupt to the vCPU running at
> + * the least privilege level.
> + *
> + * Fallthrough
> + */
> +case dest_Fixed:
> +for_each_vcpu ( d, v )
> +if ( vlapic_match_dest(vcpu_vlapic(v), NULL, 0, dest, dest_mode) 
> )
> +__set_bit(v->vcpu_id, vcpus);
> +break;
> +
> +default:
> +gprintk(XENLOG_WARNING, "unsupported interrupt delivery mode %u\n",
> +delivery_mode);
> +return -EINVAL;
> +}
> +
> +return 0;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 9466258d6f..9d9c6d391a 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -112,6 +112,25 @@ static void sync_pir_to_irr(struct vcpu *v)
>  alternative_vcall(hvm_funcs.sync_pir_to_irr, v);
>  }
>  
> +void domain_sync_vlapic_pir(struct domain *d, unsigned long *vcpus)
> +{
> +unsigned int id;
> +
> +if ( !bitmap_weight(vcpus, d->max_vcpus) )
> +return;
> +
> +for ( id = find_first_bit(vcpus, d->max_vcpus);
> +  id < d->max_vcpus;
> +  id = find_next_bit(vcpus, d->max_vcpus, id + 1) )
> +{
> +if ( d->vcpu[id] != current )
> +vcpu_pause(d->vcpu[id]);
> +sync_pir_to_irr(d->vcpu[id]);
> +if ( d->vcpu[id] != current )
> +vcpu_unpause(d->vcpu[id]);
> +}
> +}
> +
>  static int vlapic_find_highest_irr(struct vlapic *vlapic)
>  {
>  sync_pir_to_irr(vlapic_vcpu(vlapic));
> diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
> index 6597d9f719..66891d7d20 100644
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -121,29 +121,6 @@ void vmsi_deliver_pirq(struct domain *d, const struct 
> hvm_pirq_dpci *pirq_dpci)
>  vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
>  }
>  
> -/* Return value, -1 : multi-dests, non-negative value: dest_vcpu_id */
> -int hvm_girq_dest_2_vcpu_id(struct domain *d, uint8_t dest, uint8_t 
> dest_mode)
> -{
> -int dest_vcpu_id = -1, w = 0;
> -struct vcpu *v;
> -
> -if ( d->max_vcpus == 1 )
> -return 0;
> - 
> -for_each_vcpu ( d, v )

Re: [Xen-devel] [PATCH 07/24] golang/xenlight: define StringList builtin type

2019-11-13 Thread Nick Rosbrook

> Doesn't this method want a pointer receiver?

Yes, since I'm allocating a new slice. If I wasn't allocating a new
slice, this would be okay since the slice contains a pointer to the
underlying array.

-NR

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 144068: all pass - PUSHED

2019-11-13 Thread osstest service owner

flight 144068 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144068/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf bfcf262488a140550a53361c225a9b2b1bee0db8
baseline version:
 ovmf e92b155740cdbf10a85ed8f37f69da0991fc8275

Last test of basis   144046  2019-11-12 12:17:23 Z1 days
Testing same since   144068  2019-11-13 02:39:00 Z0 days1 attempts


People who touched revisions under test:
  Ming Tan 
  Tan, Ming 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   e92b155740..bfcf262488  bfcf262488a140550a53361c225a9b2b1bee0db8 -> 
xen-tested-master

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 06/24] golang/xenlight: re-name Bitmap marshaling functions

2019-11-13 Thread Nick Rosbrook

> Any particular reason to use `cslice` here rather than `mapslice` (or
> vice versa)?
>
> Not a big deal, but since they're of the came element in the C struct,
> it seems like it would be better to give them the same name.  (Don't
> have a strong opinion on which one).

IIRC, I found the name `mapslice` a little confusing, since it wasn't
of type []map[T1]T2. But, as to the inconsistent naming between the
two functions, I agree. I'll name them both `cslice`.

-NR

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits

2019-11-13 Thread Tamas K Lengyel

On Wed, Nov 13, 2019 at 9:52 AM Jan Beulich  wrote:
>
> On 13.11.2019 15:57, Tamas K Lengyel wrote:
> > On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel  wrote:
> >>
> >> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich  wrote:
> >>>
> >>> On 12.11.2019 15:05, Tamas K Lengyel wrote:
>  On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich  wrote:
> > On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> >> +else
> >> +{
> >> +rc = p2m_set_suppress_ve_multi(d, _ve);
> >> +
> >> +if ( rc == -ERESTART )
> >> +if ( __copy_field_to_guest(guest_handle_cast(arg,
> >> +   xen_hvm_altp2m_op_t),
> >> +   , u.suppress_ve.opaque) )
> >> +rc = -EFAULT;
> >
> > If the operation is best effort, _some_ indication of failure should
> > still be handed back to the caller. Whether that's through the opaque
> > field or by some other means is secondary. If not via that field
> > (which would make the outer of the two if()-s disappear), please fold
> > the if()-s.
> 
>  At least for mem_sharing_range_op we also do a best-effort and don't
>  return an error for pages where it wasn't possible to share. So I
>  don't think it's absolutely necessary to do that, especially if the
>  caller can't do anything about those errors anyway.
> >>>
> >>> mem-sharing is a little different in nature, isn't it? If you
> >>> can't share a page, both involved guests will continue to run
> >>> with their own instances. If you want to suppress #VE delivery
> >>> and it fails, behavior won't be transparently correct, as
> >>> there'll potentially be #VE when there should be none. Whether
> >>> that's benign to the guest very much depends on its handler.
> >>
> >> Makes me wonder whether it would make more sense to flip this thing on
> >> its head and have supress_ve be set by default (since its ignored by
> >> default) and then have pages for which the EPT violation should be
> >> convertible to #VE be specifically enabled by turning suppress_ve off.
> >> That would eliminate the possibility of having the in-guest handler
> >> getting #VE for pages it is not ready to handle. The hypervisor (and
> >> the external VMI toolstack) OTOH should always be in a position to
> >> handle EPT violations it itself causes by changing the page
> >> permissions.
> >
> > Actually, now that I looked at it, that's _exactly_ what we do
> > already. The suppress_ve bit is always set for all EPT pages. So this
> > operation here is going to be used to enable #VE for pages, not the
> > other way around. So there wouldn't be a case of "potentially be #VE
> > when there should be none".
>
> But this doesn't change the bottom line of my earlier comment: It's
> as bad to an OS to see too many #VE as it is to miss any that are
> expected.

Fair enough.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13] xen/sched: Render sibling/core masks with %pbl to improve 'r' debugkey

2019-11-13 Thread Andrew Cooper

For system with large numbers of CPUs, the 'r' debugkey is unwieldy.  Sibling
and core masks are a single block of adjacent bits, so are vastly shorter to
render with %pbl.

Before:
  (XEN) CPU[00] nr_run=0, sort=157, 
sibling=,,,,,,,0003,
 core=,,,,,,,
  (XEN) CPU[01] nr_run=0, sort=13750, 
sibling=,,,,,,,0003,
 core=,,,,,,,
  (XEN) CPU[02] nr_run=0, sort=188, 
sibling=,,,,,,,000c,
 core=,,,,,,,
  (XEN) CPU[03] nr_run=0, sort=13730, 
sibling=,,,,,,,000c,
 core=,,,,,,,

After:
  (XEN) CPU[00] nr_run=0, sort=1169, sibling={0-1}, core={0-127}
  (XEN) CPU[01] nr_run=0, sort=2488, sibling={0-1}, core={0-127}
  (XEN) CPU[02] nr_run=0, sort=1210, sibling={2-3}, core={0-127}
  (XEN) CPU[03] nr_run=0, sort=2476, sibling={2-3}, core={0-127}

Signed-off-by: Andrew Cooper 
---
CC: Juergen Gross 
CC: Dario Faggioli 
CC: George Dunlap 

4.13 nice-to-have.  Not strictly required, but it is a low risk change which
improves diagnostics.
---
 xen/common/sched_credit.c  | 2 +-
 xen/common/sched_credit2.c | 2 +-
 xen/common/sched_null.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 645cdc5e9a..aa41a3301b 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -2065,7 +2065,7 @@ csched_dump_pcpu(const struct scheduler *ops, int cpu)
 spc = CSCHED_PCPU(cpu);
 runq = >runq;
 
-printk("CPU[%02d] nr_run=%d, sort=%d, sibling=%*pb, core=%*pb\n",
+printk("CPU[%02d] nr_run=%d, sort=%d, sibling={%*pbl}, core={%*pbl}\n",
cpu, spc->nr_runnable, spc->runq_sort_last,
CPUMASK_PR(per_cpu(cpu_sibling_mask, cpu)),
CPUMASK_PR(per_cpu(cpu_core_mask, cpu)));
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index af58ee161d..f7c477053c 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -3658,7 +3658,7 @@ dump_pcpu(const struct scheduler *ops, int cpu)
 struct csched2_private *prv = csched2_priv(ops);
 struct csched2_unit *svc;
 
-printk("CPU[%02d] runq=%d, sibling=%*pb, core=%*pb\n",
+printk("CPU[%02d] runq=%d, sibling={%*pbl}, core={%*pbl}\n",
cpu, c2r(cpu),
CPUMASK_PR(per_cpu(cpu_sibling_mask, cpu)),
CPUMASK_PR(per_cpu(cpu_core_mask, cpu)));
diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index da3fe29f21..3f3418c9b1 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -926,7 +926,7 @@ static void null_dump_pcpu(const struct scheduler *ops, int 
cpu)
 
 lock = pcpu_schedule_lock_irqsave(cpu, );
 
-printk("CPU[%02d] sibling=%*pb, core=%*pb",
+printk("CPU[%02d] sibling={%*pbl}, core={%*pbl}",
cpu, CPUMASK_PR(per_cpu(cpu_sibling_mask, cpu)),
CPUMASK_PR(per_cpu(cpu_core_mask, cpu)));
 if ( per_cpu(npc, cpu).unit != NULL )
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 13/24] golang/xenlight: re-factor Hwcap type implementation

2019-11-13 Thread George Dunlap

On 10/7/19 4:13 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Re-define Hwcap as [8]uint32, and implement toC function. Also, re-name and
> modify signature of toGo function to fromC.
> 
> Signed-off-by: Nick Rosbrook 

Looks good.  Just one comment...

> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> 
>  tools/golang/xenlight/xenlight.go | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index 3e3753f92e..8d520bbd98 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -307,20 +307,29 @@ type Context struct {
>   logger *C.xentoollog_logger_stdiostream
>  }
>  
> -type Hwcap []C.uint32_t
> -
> -func (chwcap C.libxl_hwcap) toGo() (ghwcap Hwcap) {
> - // Alloc a Go slice for the bytes
> - size := 8
> - ghwcap = make([]C.uint32_t, size)
> +// Hwcap represents a libxl_hwcap.
> +type Hwcap [8]uint32
>  
> +func (hwcap *Hwcap) fromC(chwcap *C.libxl_hwcap) error {
>   // Make a slice pointing to the C array
> - mapslice := (*[1 << 
> 30]C.uint32_t)(unsafe.Pointer([0]))[:size:size]
> + mapslice := (*[8]C.uint32_t)(unsafe.Pointer(chwcap))

To be pedantic, this isn't a slice anymore. :-)  Do you want to change
this to 'b' (or maybe 'u' or something like that) and fix the comment?

With that changed:

Reviewed-by: George Dunlap 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 12/24] golang/xenlight: re-factor Uuid type implementation

2019-11-13 Thread George Dunlap

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Re-define Uuid as [16]byte and implement fromC, toC, and String functions.
> 
> Signed-off-by: Nick Rosbrook 
> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> 
>  tools/golang/xenlight/xenlight.go | 37 +--
>  1 file changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index 9c384485e1..3e3753f92e 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -86,7 +86,40 @@ type Devid int
>  
>  type MemKB uint64
>  
> -type Uuid C.libxl_uuid
> +// Uuid is a domain UUID.
> +type Uuid [16]byte
> +
> +// String formats a Uuid in the form "-xx-xx-xx-xx".
> +func (u Uuid) String() string {
> + s := "%x%x%x%x-%x%x-%x%x-%x%x-%x%x%x%x%x%x"
> + opts := make([]interface{}, 16)
> +
> + for i, v := range u {
> + opts[i] = v
> + }
> +
> + return fmt.Sprintf(s, opts...)

*Sigh*  Is there really no better way to do this?  (Not complaining at
you, more at the language really...)

Everything else looks good.

 -George



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 11/24] golang/xenlight: define CpuidPolicyList builtin type

2019-11-13 Thread George Dunlap

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Define CpuidPolicyList as a wrapper struct with field val of type
> *C.libxl_cpuid_policy_list and implement fromC and toC functions.
> 
> Signed-off-by: Nick Rosbrook 
> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> 
>  tools/golang/xenlight/xenlight.go | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index d41de253f3..9c384485e1 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -249,6 +249,26 @@ type EvLink struct{}
>  func (el *EvLink) fromC(cel *C.libxl_ev_link) error  { return nil }
>  func (el *EvLink) toC() (cel C.libxl_ev_link, err error) { return }
>  
> +// CpuidPolicyList represents a libxl_cpuid_policy_list.
> +type CpuidPolicyList struct {
> + val *C.libxl_cpuid_policy_list
> +}

Hmm, this introduces a pretty significant risk of memory leaks; but I
don't really see any way around it.  I guess we really want to do some
SetFinalizer() magic on this to call libxl_cpuid_dispose()?

We might also want to add something like a .Dispose() method to have
predictable memory effects.  But then do we want to have a .Dispose()
method on all types that might contain a CpuidPolicyList?  Technically
we're supposed to, so we might have to. (And now I'm having deja vu,
like we've had this discussion before, but I can't seem to find it.)

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

2019-11-13 Thread osstest service owner

flight 144082 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144082/

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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  85e1424de2dda289a4ee92e6b4f5328dd10e75ae
baseline version:
 xen  8c4330818f6ee70cbf7428a40a28a73df1272d10

Last test of basis   144057  2019-11-12 18:00:44 Z0 days
Testing same since   144082  2019-11-13 15:00:49 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   8c4330818f..85e1424de2  85e1424de2dda289a4ee92e6b4f5328dd10e75ae -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen: make debugger support configurable

2019-11-13 Thread Andrew Cooper

On 13/11/2019 16:22, Juergen Gross wrote:
> Debugger support in the hypervisor is rarely used and it is opening a
> way for dom0 to modify the running hypervisor by very easy means.
>
> Add a Kconfig option to control support of gdbsx. Default is off.
>
> Signed-off-by: Juergen Gross 
> ---
>  xen/Kconfig.debug  |  4 
>  xen/arch/x86/Kconfig   |  1 -
>  xen/arch/x86/domctl.c  |  4 
>  xen/common/Kconfig |  3 ---
>  xen/common/domain.c|  2 +-
>  xen/include/asm-x86/debugger.h | 30 ++
>  xen/include/xen/sched.h|  4 
>  7 files changed, 31 insertions(+), 17 deletions(-)
>
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 22573e74db..84a6e1b8eb 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -13,9 +13,13 @@ config DEBUG
>  
>  if DEBUG || EXPERT = "y"
>  
> +config GDBSX
> + bool
> +
>  config CRASH_DEBUG
>   bool "Crash Debugging Support"
>   depends on X86
> + select GDBSX
>   ---help---
> If you want to attach gdb to Xen to debug Xen if it crashes
> then say Y.

CRASH_DEBUG and GDBSX are unrelated.

The former is gdbstub over serial for Xen itself (which I've never seen
used, and therefore doubt functions), while the latter is a set of dom0
hypercalls used by the gdbsx utility.

I'm happy to make CONFIG_GDBSX more useful than it currently is, but I
don't think the two options want conflating.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 2/7] WIP: Compilation with ARM DS-6 compiler

2019-11-13 Thread Artem Mygaiev

Hi Jan,

Sorry for delayed reply

On Thu, 2019-11-07 at 08:31 +0100, Jan Beulich wrote:
> On 06.11.2019 23:08, Artem Mygaiev wrote:
> > On Wed, Nov 6, 2019 at 4:28 PM Jan Beulich <
> > jbeul...@suse.com
> > > wrote:
> > > On 06.11.2019 10:19, Andrii Anisov wrote:
> > > > --- a/Config.mk
> > > > +++ b/Config.mk
> > > > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
> > > > 
> > > >  $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
> > > > statement)
> > > >  $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
> > > > +ifneq ($(armds),y)
> > > >  $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
> > > > +endif
> > > >  $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
> > > > 
> > > >  LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> > > 
> > > ... this would be necessary.
> > 
> > I am very sorry, this patch does not have a proper description
> > indeed.
> > 
> > For this particular change - arm clang does not undestand
> > -Wno-unused-but-set-variable
> > option at all, that is why it is under !$(armds)
> 
> But avoiding to add options which the compiler doesn't understand
> is the purpose of using cc-option-add, rather than blindly
> adding
> them to CFLAGS. What am I missing here?

You are right, the script shall check the compiler option and avoid
including it to CFLAGS. But armclang require '--target=...' to be
specified in order to operate properly, and the proper fix shall be
something like this (instead of 'ifneq' hack above):

diff --git a/Config.mk b/Config.mk
index 01487a7..abe8e44 100644
--- a/Config.mk
+++ b/Config.mk
@@ -107,7 +107,7 @@ cc-option = $(shell if test -z "`echo 'void*p=1;' | \
 # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6)
 cc-option-add = $(eval $(call cc-option-add-closure,$(1),$(2),$(3)))
 define cc-option-add-closure
-ifneq ($$(call cc-option,$$($(2)),$(3),n),n)
+ifneq ($$(call cc-option,$$($(2) $(1)),$(3),n),n)
 $(1) += $(3)
 endif
 endef

so that CFLAGS that are already defined and include '--target=...'
option from config/arm*.mk are passed to compiler to make it happy. I
am not sure if this breaks anything else so decided to go with ugly
'ifneq' hack and check how this can be solved later on.

> Jan
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> 
> https://urldefense.com/v3/__https://lists.xenproject.org/mailman/listinfo/xen-devel__;!K6dmGCEab4ueJg!mfAKUfGDnRPgNHksMlffaLrptu7demkLHApa3STsHRSKyoHnusYbCLzhLjD8K_vpFw$
>  
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files

2019-11-13 Thread Andrii Anisov


Dear Julien,

On 13.11.19 07:51, Julien Grall wrote:
Was this reported to Arm? 

All mentioned ARM Compiler issues were reported to ARM. Unfortunately, ARM 
hesitated to discus them in community, yet asked to open support cases, e.g. 
[1].
All issues and their WA's were acknowledged by ARM in correspondent support 
cases. Except C-style shifts issue what is not a bug but the documented feature 
[2], and ARM's answer about it was really uncertain.
Only after getting answer for all cases I finalized the patches.



If so, what was there answer?


I already cited the answer for this particular issue while answering Stefano.

[1] 
https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/44287/arm-compiler-6-compiles-data-only-c-file-with-softvfp-attribute
[2] 
https://developer.arm.com/docs/100070/0612/scatter-file-syntax/expression-evaluation-in-scatter-files/expression-rules-in-scatter-files

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] x86: fix clang .macro retention check

2019-11-13 Thread Jan Beulich

There were two problems here: The first closing parentheses got parsed
by make to end the $(call invocation, and the escaping of the quotes
wasn't right either, as there's nowhere they would get un-escaped.

Signed-off-by: Jan Beulich 
---
This needs to be tested in an environment where this was actually found
to matter; I can't see how it can have worked in its former shape. I
also don't understand why the same commit introducing the check that
gets fixed here put the .skip check in xen/Rules.mk - the only use of
.skip that I can spot is in x86 code.

--- a/Config.mk
+++ b/Config.mk
@@ -6,6 +6,8 @@ endif
 
 # Convenient variables
 comma   := ,
+open:= (
+close   := )
 squote  := '
 #' Balancing squote, to help syntax highlighting
 empty   :=
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -82,6 +64,6 @@ $(call as-option-add,CFLAGS,CC,".include
 # Check whether clang keeps .macro-s between asm()-s:
 # https://bugs.llvm.org/show_bug.cgi?id=36110
 $(call as-option-add,CFLAGS,CC,\
- ".macro FOO\n.endm\"); asm volatile (\".macro 
FOO\n.endm",\
+ ".macro FOO\n.endm"$$(close); asm volatile 
$$(open)".macro FOO\n.endm",\
  -no-integrated-as)
 endif

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen: make debugger support configurable

2019-11-13 Thread Jan Beulich

On 13.11.2019 17:22, Juergen Gross wrote:
> Debugger support in the hypervisor is rarely used and it is opening a
> way for dom0 to modify the running hypervisor by very easy means.
> 
> Add a Kconfig option to control support of gdbsx. Default is off.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Jan Beulich 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits

2019-11-13 Thread Jan Beulich

On 13.11.2019 15:57, Tamas K Lengyel wrote:
> On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel  wrote:
>>
>> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich  wrote:
>>>
>>> On 12.11.2019 15:05, Tamas K Lengyel wrote:
 On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich  wrote:
> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
>> +else
>> +{
>> +rc = p2m_set_suppress_ve_multi(d, _ve);
>> +
>> +if ( rc == -ERESTART )
>> +if ( __copy_field_to_guest(guest_handle_cast(arg,
>> +   xen_hvm_altp2m_op_t),
>> +   , u.suppress_ve.opaque) )
>> +rc = -EFAULT;
>
> If the operation is best effort, _some_ indication of failure should
> still be handed back to the caller. Whether that's through the opaque
> field or by some other means is secondary. If not via that field
> (which would make the outer of the two if()-s disappear), please fold
> the if()-s.

 At least for mem_sharing_range_op we also do a best-effort and don't
 return an error for pages where it wasn't possible to share. So I
 don't think it's absolutely necessary to do that, especially if the
 caller can't do anything about those errors anyway.
>>>
>>> mem-sharing is a little different in nature, isn't it? If you
>>> can't share a page, both involved guests will continue to run
>>> with their own instances. If you want to suppress #VE delivery
>>> and it fails, behavior won't be transparently correct, as
>>> there'll potentially be #VE when there should be none. Whether
>>> that's benign to the guest very much depends on its handler.
>>
>> Makes me wonder whether it would make more sense to flip this thing on
>> its head and have supress_ve be set by default (since its ignored by
>> default) and then have pages for which the EPT violation should be
>> convertible to #VE be specifically enabled by turning suppress_ve off.
>> That would eliminate the possibility of having the in-guest handler
>> getting #VE for pages it is not ready to handle. The hypervisor (and
>> the external VMI toolstack) OTOH should always be in a position to
>> handle EPT violations it itself causes by changing the page
>> permissions.
> 
> Actually, now that I looked at it, that's _exactly_ what we do
> already. The suppress_ve bit is always set for all EPT pages. So this
> operation here is going to be used to enable #VE for pages, not the
> other way around. So there wouldn't be a case of "potentially be #VE
> when there should be none".

But this doesn't change the bottom line of my earlier comment: It's
as bad to an OS to see too many #VE as it is to miss any that are
expected.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 02/14] mm/mmu_notifier: add an interval tree notifier

2019-11-13 Thread Jason Gunthorpe

On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote:
> > +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
> > + struct mm_struct *mm, unsigned long start,
> > + unsigned long length,
> > + const struct mmu_interval_notifier_ops 
> > *ops);
> > +int mmu_interval_notifier_insert_locked(
> > +   struct mmu_interval_notifier *mni, struct mm_struct *mm,
> > +   unsigned long start, unsigned long length,
> > +   const struct mmu_interval_notifier_ops *ops);
> 
> Very inconsistent indentation between these two related functions.

clang-format.. The kernel config is set to prefer a line up under the
( if all the arguments will fit within the 80 cols otherwise it does a
1 tab continuation indent.

> > +   /*
> > +* The inv_end incorporates a deferred mechanism like
> > +* rtnl_unlock(). Adds and removes are queued until the final inv_end
> > +* happens then they are progressed. This arrangement for tree updates
> > +* is used to avoid using a blocking lock during
> > +* invalidate_range_start.
> 
> Nitpick:  That comment can be condensed into one less line:

The rtnl_unlock can move up a line too. My editor is failing me on
this.

> > +   /*
> > +* TODO: Since we already have a spinlock above, this would be faster
> > +* as wake_up_q
> > +*/
> > +   if (need_wake)
> > +   wake_up_all(_mm->wq);
> 
> So why is this important enough for a TODO comment, but not important
> enough to do right away?

Lets drop the comment, I'm noto sure wake_up_q is even a function this
layer should be calling.
 
> > +* release semantics on the initialization of the mmu_notifier_mm's
> > + * contents are provided for unlocked readers.  acquire can only be
> > + * used while holding the mmgrab or mmget, and is safe because once
> > + * created the mmu_notififer_mm is not freed until the mm is
> > + * destroyed.  As above, users holding the mmap_sem or one of the
> > + * mm_take_all_locks() do not need to use acquire semantics.
> >  */
> 
> Some spaces instead of tabs here.

Got it

> > +static int __mmu_interval_notifier_insert(
> > +   struct mmu_interval_notifier *mni, struct mm_struct *mm,
> > +   struct mmu_notifier_mm *mmn_mm, unsigned long start,
> > +   unsigned long length, const struct mmu_interval_notifier_ops *ops)
> 
> Odd indentation - we usuall do two tabs (my preference) or align after
> the opening brace.

This is one tab. I don't think one tab is odd, it seems pretty popular
even just in mm/.

But two tabs is considered usual? I didn't even know that.

> > + * This function must be paired with mmu_interval_notifier_insert(). It 
> > cannot be
> 
> line > 80 chars.

got it, was missed during the rename

> Otherwise this looks good and very similar to what I reviewed earlier:
> 
> Reviewed-by: Christoph Hellwig 

Thanks a bunch, your comments have been very helpful on this series!

Jason

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files

2019-11-13 Thread Andrii Anisov


Hello Stefano,

On 11.11.19 22:57, Stefano Stabellini wrote:

Oh man, this is truly horrible.


I feel your pain.



If we really have to do this please:

- use the same dummy function name in all files


No, because


- the function should be static


those functions will not handle the case if are static.

ARM commented the issue in the correspondent support case:

"A known workaround is to edit the source file and add an unused empty 
function, as you’ve already found. By default, an unused empty function should be 
removed from the final image by the unused section elimination feature of the 
linker, so it shouldn’t have a code size impact.

A command-line option workaround isn’t available. We’ll now set this case to a 
“Defect/Enhancement” state while the issue remains unfixed, and will keep you 
updated accordingly."



- hiding the function within a #ifdef ARMCC block
- potentially hide the whole horrible hack behind a #define so that it
   would become at the call site:

  +ARMCC_DUMMY_FUNC_HACK()


This is quite reasonable.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/3] xen/mcelog: add PPIN to record when available

2019-11-13 Thread Boris Ostrovsky

On 11/13/19 8:44 AM, Jan Beulich wrote:
> On 13.11.2019 01:11, Boris Ostrovsky wrote:
>> On 11/11/19 9:46 AM, Jan Beulich wrote:
>>> --- a/arch/x86/include/asm/msr-index.h
>>> +++ b/arch/x86/include/asm/msr-index.h
>>> @@ -393,6 +393,8 @@
>>>  #define MSR_AMD_PSTATE_DEF_BASE0xc0010064
>>>  #define MSR_AMD64_OSVW_ID_LENGTH   0xc0010140
>>>  #define MSR_AMD64_OSVW_STATUS  0xc0010141
>>> +#define MSR_AMD_PPIN_CTL   0xc00102f0
>>> +#define MSR_AMD_PPIN   0xc00102f1
>> Which processors are these defined for? I looked at a couple (fam 15h
>> and 17h) and didn't see those. And I don't see them in Linux.
> Certain Fam17 ones, Rome in particular (which is where I've
> tested this).

I was looking at Naples, can't find Rome on AMD's page.

>
>>> --- a/include/xen/interface/xen-mca.h
>>> +++ b/include/xen/interface/xen-mca.h
>>> @@ -332,7 +332,11 @@ struct xen_mc {
>>>  };
>>>  DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
>>>  
>>> -/* Fields are zero when not available */
>>> +/*
>>> + * Fields are zero when not available. Also, this struct is shared with
>>> + * userspace mcelog and thus must keep existing fields at current offsets.
>>> + * Only add new fields to the end of the structure
>>> + */
>>>  struct xen_mce {
>> Why is this structure is part of the interface?
> That's a question to whoever put it there. There look to have
> been decisions (see also patch 1) to have the Linux clones of
> Xen's public headers deviate far more from their original
> than I would consider reasonable.

Yes, this goes back to when the file was first created.

Reviewed-by: Boris Ostrovsky 

(but if you want to move non-interface parts into, say,
drivers/xen/mcelog.h I won't stand in your way ;-) )


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 10/24] golang/xenlight: define EvLink builtin as empty struct

2019-11-13 Thread George Dunlap

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Define EvLink as empty struct as there is currently no reason the internal of
> this type should be used in Go.
> 
> Implement fromC and toC functions as no-ops.
> 
> Signed-off-by: Nick Rosbrook 

Reviewed-by: George Dunlap 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] xen: make debugger support configurable

2019-11-13 Thread Juergen Gross

Debugger support in the hypervisor is rarely used and it is opening a
way for dom0 to modify the running hypervisor by very easy means.

Add a Kconfig option to control support of gdbsx. Default is off.

Signed-off-by: Juergen Gross 
---
 xen/Kconfig.debug  |  4 
 xen/arch/x86/Kconfig   |  1 -
 xen/arch/x86/domctl.c  |  4 
 xen/common/Kconfig |  3 ---
 xen/common/domain.c|  2 +-
 xen/include/asm-x86/debugger.h | 30 ++
 xen/include/xen/sched.h|  4 
 7 files changed, 31 insertions(+), 17 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 22573e74db..84a6e1b8eb 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -13,9 +13,13 @@ config DEBUG
 
 if DEBUG || EXPERT = "y"
 
+config GDBSX
+   bool
+
 config CRASH_DEBUG
bool "Crash Debugging Support"
depends on X86
+   select GDBSX
---help---
  If you want to attach gdb to Xen to debug Xen if it crashes
  then say Y.
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 28b3b4692a..c72da8964a 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -13,7 +13,6 @@ config X86
select HAS_EHCI
select HAS_EX_TABLE
select HAS_FAST_MULTIPLY
-   select HAS_GDBSX
select HAS_IOPORTS
select HAS_KEXEC
select MEM_ACCESS_ALWAYS_ON
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 43e368d63b..90e36b9ad8 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_GDBSX
 static int gdbsx_guest_mem_io(domid_t domid, struct xen_domctl_gdbsx_memio 
*iop)
 {
 void * __user gva = (void *)iop->gva, * __user uva = (void *)iop->uva;
@@ -45,6 +46,7 @@ static int gdbsx_guest_mem_io(domid_t domid, struct 
xen_domctl_gdbsx_memio *iop)
 
 return iop->remain ? -EFAULT : 0;
 }
+#endif
 
 static void domain_cpu_policy_changed(struct domain *d)
 {
@@ -912,6 +914,7 @@ long arch_do_domctl(
 }
 #endif
 
+#ifdef CONFIG_GDBSX
 case XEN_DOMCTL_gdbsx_guestmemio:
 domctl->u.gdbsx_guest_memio.remain = domctl->u.gdbsx_guest_memio.len;
 ret = gdbsx_guest_mem_io(domctl->domain, >u.gdbsx_guest_memio);
@@ -976,6 +979,7 @@ long arch_do_domctl(
 copyback = true;
 break;
 }
+#endif
 
 case XEN_DOMCTL_setvcpuextstate:
 case XEN_DOMCTL_getvcpuextstate:
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index f754741972..7bde6aff02 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -57,9 +57,6 @@ config HAS_UBSAN
 config HAS_KEXEC
bool
 
-config HAS_GDBSX
-   bool
-
 config HAS_IOPORTS
bool
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 66c7fc..b4e041ffd0 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -915,7 +915,7 @@ void vcpu_end_shutdown_deferral(struct vcpu *v)
 vcpu_check_shutdown(v);
 }
 
-#ifdef CONFIG_HAS_GDBSX
+#ifdef CONFIG_GDBSX
 void domain_pause_for_debugger(void)
 {
 struct vcpu *curr = current;
diff --git a/xen/include/asm-x86/debugger.h b/xen/include/asm-x86/debugger.h
index b1b627f1fa..4a8f226b86 100644
--- a/xen/include/asm-x86/debugger.h
+++ b/xen/include/asm-x86/debugger.h
@@ -47,18 +47,6 @@ static inline bool debugger_trap_fatal(
 /* Int3 is a trivial way to gather cpu_user_regs context. */
 #define debugger_trap_immediate() __asm__ __volatile__ ( "int3" );
 
-#else
-
-static inline bool debugger_trap_fatal(
-unsigned int vector, struct cpu_user_regs *regs)
-{
-return false;
-}
-
-#define debugger_trap_immediate() ((void)0)
-
-#endif
-
 static inline bool debugger_trap_entry(
 unsigned int vector, struct cpu_user_regs *regs)
 {
@@ -88,4 +76,22 @@ unsigned int dbg_rw_mem(void * __user addr, void * __user 
buf,
 unsigned int len, domid_t domid, bool toaddr,
 uint64_t pgd3);
 
+#else
+
+static inline bool debugger_trap_fatal(
+unsigned int vector, struct cpu_user_regs *regs)
+{
+return false;
+}
+
+#define debugger_trap_immediate() ((void)0)
+
+static inline bool debugger_trap_entry(
+unsigned int vector, struct cpu_user_regs *regs)
+{
+return false;
+}
+
+#endif
+
 #endif /* __X86_DEBUGGER_H__ */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 9f7bc69293..094003f562 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -652,7 +652,11 @@ void domain_destroy(struct domain *d);
 int domain_kill(struct domain *d);
 int domain_shutdown(struct domain *d, u8 reason);
 void domain_resume(struct domain *d);
+#ifdef CONFIG_GDBSX
 void domain_pause_for_debugger(void);
+#else
+static inline void domain_pause_for_debugger(void) { }
+#endif
 
 int domain_soft_reset(struct domain *d);
 
-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 09/24] golang/xenlight: define MsVmGenid builtin type

2019-11-13 Thread George Dunlap

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Define MsVmGenid as [int(C.LIBXL_MS_VM_GENID_LEN)]byte and implement fromC 
> and toC functions.
> 
> Signed-off-by: Nick Rosbrook 
> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> 
>  tools/golang/xenlight/xenlight.go | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index 3b7824b284..6aca5b89c0 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -216,6 +216,29 @@ func (mac *Mac) toC() (C.libxl_mac, error) {
>   return cmac, nil
>  }
>  
> +// MsVmGenid represents a libxl_ms_vm_genid.
> +type MsVmGenid [int(C.LIBXL_MS_VM_GENID_LEN)]byte
> +
> +func (mvg *MsVmGenid) fromC(cmvg *C.libxl_ms_vm_genid) error {
> + b := 
> (*[int(C.LIBXL_MS_VM_GENID_LEN)]C.uint8_t)(unsafe.Pointer([0]))
> +
> + for i, v := range b {
> + mvg[i] = byte(v)
> + }

It's slightly annoying to have to do this loop, but I guess given that
we have to technically cast each element of the array.  Hopefully the
compiler will eventually be able to figure out what's going on here and
just do a memcpy.

> +
> + return nil
> +}
> +
> +func (mvg *MsVmGenid) toC() (C.libxl_ms_vm_genid, error) {

Hmm, I guess we want a pointer receiver here to make sure we don't end
up doing a 16-byte copy.

Reviewed-by: George Dunlap 

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13 v4 1/3] vmx: add ASSERT to prevent syncing PIR to IRR...

2019-11-13 Thread Roger Pau Monne

... if the vCPU is different than the one currently running or if it's
running on a different pCPU.

No functional change intended.

Suggested by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Cc: Juergen Gross 
---
 xen/arch/x86/hvm/vmx/vmx.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index a55ff37733..e5e674c373 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2054,6 +2054,17 @@ static void vmx_sync_pir_to_irr(struct vcpu *v)
 unsigned int group, i;
 DECLARE_BITMAP(pending_intr, NR_VECTORS);
 
+if ( v != current && v->is_running )
+{
+/*
+ * Syncing PIR to IRR must not be done behind the back of the CPU,
+ * since the IRR is controlled by the hardware when the vCPU is
+ * executing.
+ */
+ASSERT_UNREACHABLE();
+return;
+}
+
 if ( !pi_test_and_clear_on(>arch.hvm.vmx.pi_desc) )
 return;
 
-- 
2.24.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13 v4 3/3] x86/vioapic: sync PIR to IRR when modifying entries

2019-11-13 Thread Roger Pau Monne

If posted interrutps are being used sync PIR to IRR when an unmasked
vIO-APIC entry is modified. Do this in order to prevent vectors in the
IRR being set after a change to a vIO-APIC entry has been performed.

Signed-off-by: Roger Pau Monné 
---
Cc: Juergen Gross 
---
 xen/arch/x86/hvm/vioapic.c | 46 +-
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index 9aeef32a14..90e6d1c4e6 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -212,6 +212,44 @@ static int vioapic_hwdom_map_gsi(unsigned int gsi, 
unsigned int trig,
 return ret;
 }
 
+static inline int pit_channel0_enabled(void)
+{
+return pt_active(>domain->arch.vpit.pt0);
+}
+
+static void sync_vcpus_pir(struct domain *d, union vioapic_redir_entry *ent,
+   unsigned int irq)
+{
+DECLARE_BITMAP(vcpus, MAX_VIRT_CPUS) = { };
+
+switch ( ent->fields.delivery_mode )
+{
+case dest_LowestPrio:
+case dest_Fixed:
+#ifdef IRQ0_SPECIAL_ROUTING
+if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() )
+{
+__set_bit(0, vcpus);
+break;
+}
+#endif
+hvm_intr_get_dests(d, ent->fields.dest_id, ent->fields.dest_mode,
+   ent->fields.delivery_mode, vcpus);
+break;
+
+case dest_NMI:
+/* Nothing to do, NMIs are not signaled on the PIR. */
+break;
+
+default:
+gdprintk(XENLOG_WARNING, "unsupported delivery mode %02u\n",
+ ent->fields.delivery_mode);
+break;
+}
+
+domain_sync_vlapic_pir(d, vcpus);
+}
+
 static void vioapic_write_redirent(
 struct hvm_vioapic *vioapic, unsigned int idx,
 int top_word, uint32_t val)
@@ -235,6 +273,9 @@ static void vioapic_write_redirent(
 pent = >redirtbl[idx];
 ent  = *pent;
 
+if ( !ent.fields.mask && hvm_funcs.deliver_posted_intr )
+sync_vcpus_pir(d, pent, vioapic->base_gsi + idx);
+
 if ( top_word )
 {
 /* Contains only the dest_id. */
@@ -391,11 +432,6 @@ static void ioapic_inj_irq(
 vlapic_set_irq(target, vector, trig_mode);
 }
 
-static inline int pit_channel0_enabled(void)
-{
-return pt_active(>domain->arch.vpit.pt0);
-}
-
 static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin)
 {
 uint16_t dest = vioapic->redirtbl[pin].fields.dest_id;
-- 
2.24.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13 v4 2/3] x86/passthrough: fix migration of MSI when using posted interrupts

2019-11-13 Thread Roger Pau Monne

When using posted interrupts and the guest migrates MSI from vCPUs Xen
needs to flush any pending PIRR vectors on the previous vCPU, or else
those vectors could get wrongly injected at a later point when the MSI
fields are already updated.

The usage of a fixed vCPU in lowest priority mode when using VT-d
posted interrupts is also removed, and as a result VT-d posted
interrupts are not used together with lowest priority mode and
multiple destinations. That forces vlapic_lowest_prio to be called in
order to select the destination vCPU during interrupt dispatch.

Note that PIRR is synced to IRR both in pt_irq_destroy_bind and
pt_irq_create_bind when the interrupt delivery data is being updated.

Reported-by: Joe Jin 
Signed-off-by: Roger Pau Monné 
---
Cc: Joe Jin 
Cc: Juergen Gross 
---
Changes since v3:
 - In multi-destination mode make sure all destination vCPUs have PIR
   synced to IRR by using a bitmap.
 - Drop the bogus selection of a fixed vCPU when using lowest priority
   mode.

Changes since v2:
 - Also sync PIRR with IRR when using CPU posted interrupts.
 - Force the selection of a specific vCPU when using posted interrupts
   for multi-dest.
 - Change vmsi_deliver_pirq to honor dest_vcpu_id.

Changes since v1:
 - Store the vcpu id also in multi-dest mode if the interrupt is bound
   to a vcpu for posted delivery.
 - s/#if/#ifdef/.
---
 xen/arch/x86/hvm/hvm.c   |  31 
 xen/arch/x86/hvm/vlapic.c|  19 +
 xen/arch/x86/hvm/vmsi.c  |  23 --
 xen/drivers/passthrough/io.c | 118 ++-
 xen/include/asm-x86/hvm/hvm.h|   5 +-
 xen/include/asm-x86/hvm/vlapic.h |   3 +
 6 files changed, 110 insertions(+), 89 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 06a7b40107..0e3379fa6f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -5266,6 +5267,36 @@ void hvm_set_segment_register(struct vcpu *v, enum 
x86_segment seg,
 alternative_vcall(hvm_funcs.set_segment_register, v, seg, reg);
 }
 
+int hvm_intr_get_dests(struct domain *d, uint8_t dest, uint8_t dest_mode,
+   uint8_t delivery_mode, unsigned long *vcpus)
+{
+struct vcpu *v;
+
+switch ( delivery_mode )
+{
+case dest_LowestPrio:
+/*
+ * Get all the possible destinations, but note that lowest priority
+ * mode is only going to inject the interrupt to the vCPU running at
+ * the least privilege level.
+ *
+ * Fallthrough
+ */
+case dest_Fixed:
+for_each_vcpu ( d, v )
+if ( vlapic_match_dest(vcpu_vlapic(v), NULL, 0, dest, dest_mode) )
+__set_bit(v->vcpu_id, vcpus);
+break;
+
+default:
+gprintk(XENLOG_WARNING, "unsupported interrupt delivery mode %u\n",
+delivery_mode);
+return -EINVAL;
+}
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 9466258d6f..9d9c6d391a 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -112,6 +112,25 @@ static void sync_pir_to_irr(struct vcpu *v)
 alternative_vcall(hvm_funcs.sync_pir_to_irr, v);
 }
 
+void domain_sync_vlapic_pir(struct domain *d, unsigned long *vcpus)
+{
+unsigned int id;
+
+if ( !bitmap_weight(vcpus, d->max_vcpus) )
+return;
+
+for ( id = find_first_bit(vcpus, d->max_vcpus);
+  id < d->max_vcpus;
+  id = find_next_bit(vcpus, d->max_vcpus, id + 1) )
+{
+if ( d->vcpu[id] != current )
+vcpu_pause(d->vcpu[id]);
+sync_pir_to_irr(d->vcpu[id]);
+if ( d->vcpu[id] != current )
+vcpu_unpause(d->vcpu[id]);
+}
+}
+
 static int vlapic_find_highest_irr(struct vlapic *vlapic)
 {
 sync_pir_to_irr(vlapic_vcpu(vlapic));
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 6597d9f719..66891d7d20 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -121,29 +121,6 @@ void vmsi_deliver_pirq(struct domain *d, const struct 
hvm_pirq_dpci *pirq_dpci)
 vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
 }
 
-/* Return value, -1 : multi-dests, non-negative value: dest_vcpu_id */
-int hvm_girq_dest_2_vcpu_id(struct domain *d, uint8_t dest, uint8_t dest_mode)
-{
-int dest_vcpu_id = -1, w = 0;
-struct vcpu *v;
-
-if ( d->max_vcpus == 1 )
-return 0;
- 
-for_each_vcpu ( d, v )
-{
-if ( vlapic_match_dest(vcpu_vlapic(v), NULL, 0, dest, dest_mode) ) 
-{
-w++;
-dest_vcpu_id = v->vcpu_id;
-}
-}
-if ( w > 1 )
-return -1;
-
-return dest_vcpu_id;
-}
-
 /* MSI-X mask bit hypervisor interception */
 struct msixtbl_entry
 {
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index

[Xen-devel] [PATCH for-4.13 v4 0/3] x86/passthrough: fix interrupt migration when using posting

2019-11-13 Thread Roger Pau Monne

Hello,

The current interrupt posting code doesn't flush the PIR into the IRR
when interrupts are modified, and as a result a vCPU can receive vectors
from a tear down or moved interrupt. Fix this by making sure PIR is
always synced to IRR when vMSI or vIO-APIC interrupts are modified.

Roger Pau Monne (3):
  vmx: add ASSERT to prevent syncing PIR to IRR...
  x86/passthrough: fix migration of MSI when using posted interrupts
  x86/vioapic: sync PIR to IRR when modifying entries

 xen/arch/x86/hvm/hvm.c   |  31 
 xen/arch/x86/hvm/vioapic.c   |  46 ++--
 xen/arch/x86/hvm/vlapic.c|  19 +
 xen/arch/x86/hvm/vmsi.c  |  23 --
 xen/arch/x86/hvm/vmx/vmx.c   |  11 +++
 xen/drivers/passthrough/io.c | 118 ++-
 xen/include/asm-x86/hvm/hvm.h|   5 +-
 xen/include/asm-x86/hvm/vlapic.h |   3 +
 8 files changed, 162 insertions(+), 94 deletions(-)

-- 
2.24.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 08/24] golang/xenlight: define Mac builtin type

2019-11-13 Thread George Dunlap

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Define Mac as [6]byte and implement fromC, toC, and String functions.
> 
> Signed-off-by: Nick Rosbrook 
> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> 
>  tools/golang/xenlight/xenlight.go | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index a3a1836d31..3b7824b284 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -181,6 +181,41 @@ func (d *Defbool) toC() (C.libxl_defbool, error) {
>   return c, nil
>  }
>  
> +// Mac represents a libxl_mac, or simply a MAC address.
> +type Mac [6]byte
> +
> +// String formats a Mac address to string representation.
> +func (mac Mac) String() string {
> + s := "%x:%x:%x:%x:%x:%x"
> + opts := make([]interface{}, 6)
> +
> + for i, v := range mac {
> + opts[i] = v
> + }

What's the point of this?

I realize it's slightly annoying to have to type `mac[0], mac[1], ...`,
but I'd rather do that once than make the runtime copy everything over
into a slice of interfaces every String() call.

Also, I guess the format should be "%02x".

> +
> + return fmt.Sprintf(s, opts...)
> +}
> +
> +func (mac *Mac) fromC(cmac *C.libxl_mac) error {
> + b := (*[6]C.uint8_t)(unsafe.Pointer(cmac))
> +
> + for i, v := range b {
> + mac[i] = byte(v)
> + }
> +
> + return nil
> +}
> +
> +func (mac *Mac) toC() (C.libxl_mac, error) {

Conversely, shouldn't this be a value receiver, since we're don't want
this function to change the contents of mac?

Thanks,
 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 07/24] golang/xenlight: define StringList builtin type

2019-11-13 Thread George Dunlap

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Define StringList as []string an implement fromC and toC functions.
> 
> Signed-off-by: Nick Rosbrook 
> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> 
>  tools/golang/xenlight/xenlight.go | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index 09fcdca5d1..a3a1836d31 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -234,6 +234,35 @@ func (kvl KeyValueList) toC() (C.libxl_key_value_list, 
> error) {
>   return ckvl, nil
>  }
>  
> +// StringList represents a libxl_string_list.
> +type StringList []string
> +
> +func (sl StringList) fromC(csl *C.libxl_string_list) error {
> + size := int(C.libxl_string_list_length(csl))
> + list := (*[1 << 30]*C.char)(unsafe.Pointer(csl))[:size:size]
> +
> + sl = make([]string, size)

Doesn't this method want a pointer receiver?

Everything else looks good.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 06/24] golang/xenlight: re-name Bitmap marshaling functions

2019-11-13 Thread George Dunlap

On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook 
> 
> Re-name and modify signature of toGo function to fromC. The reason for
> using 'fromC' rather than 'toGo' is that it is not a good idea to define
> methods on the C types. Also, add error return type to Bitmap's toC function.
> 
> Finally, as code-cleanup, re-organize the Bitmap type's comments as per
> Go conventions.
> 
> Signed-off-by: Nick Rosbrook 

Acked-by: George Dunlap 

With one minor comment...


> +func (bm *Bitmap) fromC(cbm *C.libxl_bitmap) error {
> + // Alloc a Go slice for the bytes
> + size := int(cbm.size)
> + bm.bitmap = make([]C.uint8_t, size)
> +
> + // Make a slice pointing to the C array
> + mapslice := (*[1 << 30]C.uint8_t)(unsafe.Pointer(cbm._map))[:size:size]
> +
> + // And copy the C array into the Go array
> + copy(bm.bitmap, mapslice)
> +
> + return nil
> +}
> +
> +func (bm *Bitmap) toC() (C.libxl_bitmap, error) {
> + var cbm C.libxl_bitmap
> +
> + size := len(bm.bitmap)
> + cbm.size = C.uint32_t(size)
> + cbm._map = (*C.uint8_t)(C.malloc(C.ulong(cbm.size) * C.sizeof_uint8_t))
> + cslice := (*[1 << 31]C.uint8_t)(unsafe.Pointer(cbm._map))[:size:size]

Any particular reason to use `cslice` here rather than `mapslice` (or
vice versa)?

Not a big deal, but since they're of the came element in the C struct,
it seems like it would be better to give them the same name.  (Don't
have a strong opinion on which one).

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [xen-4.12-testing test] 144059: regressions - FAIL

2019-11-13 Thread Andrew Cooper

On 13/11/2019 14:42, Jan Beulich wrote:
> On 13.11.2019 12:55, osstest service owner wrote:
>> flight 144059 xen-4.12-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/144059/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. 
>> vs. 144035
> From looking at this some I get the impression that the L2 guest
> is busy-waiting in its boot loader. Seeing that the same test
> also failed for 4.11, it doesn't seem entirely impossible that
> the fixes for the two XSAs have caused a regression here. Any
> other thoughts / insights anyone?

OSSTest has no hardware which is impacted by 305, so I'm fairly
confident ruling that out.  (For affected hardware, it is only boot-time
changes.)

(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3
(raw 000306c3)

This is a Haswell box, so is impacted by 304.  (Its actually the same
CPU as my main dev box so has had a *lot* of testing in this area...)

L0 reports:

(XEN) VMX: Disabling executable EPT superpages due to CVE-2018-12207

as expected.

L1 should find that it is virtualised and turn off the mitigation, but
we don't get that far during boot.  I can't see how the nested-virt
aspect would be relevant at this point, so I can't reason about what
might have gone wrong.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits

2019-11-13 Thread Tamas K Lengyel

On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel  wrote:
>
> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich  wrote:
> >
> > On 12.11.2019 15:05, Tamas K Lengyel wrote:
> > > On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich  wrote:
> > >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> > >>> +else
> > >>> +{
> > >>> +rc = p2m_set_suppress_ve_multi(d, _ve);
> > >>> +
> > >>> +if ( rc == -ERESTART )
> > >>> +if ( __copy_field_to_guest(guest_handle_cast(arg,
> > >>> +   xen_hvm_altp2m_op_t),
> > >>> +   , u.suppress_ve.opaque) )
> > >>> +rc = -EFAULT;
> > >>
> > >> If the operation is best effort, _some_ indication of failure should
> > >> still be handed back to the caller. Whether that's through the opaque
> > >> field or by some other means is secondary. If not via that field
> > >> (which would make the outer of the two if()-s disappear), please fold
> > >> the if()-s.
> > >
> > > At least for mem_sharing_range_op we also do a best-effort and don't
> > > return an error for pages where it wasn't possible to share. So I
> > > don't think it's absolutely necessary to do that, especially if the
> > > caller can't do anything about those errors anyway.
> >
> > mem-sharing is a little different in nature, isn't it? If you
> > can't share a page, both involved guests will continue to run
> > with their own instances. If you want to suppress #VE delivery
> > and it fails, behavior won't be transparently correct, as
> > there'll potentially be #VE when there should be none. Whether
> > that's benign to the guest very much depends on its handler.
>
> Makes me wonder whether it would make more sense to flip this thing on
> its head and have supress_ve be set by default (since its ignored by
> default) and then have pages for which the EPT violation should be
> convertible to #VE be specifically enabled by turning suppress_ve off.
> That would eliminate the possibility of having the in-guest handler
> getting #VE for pages it is not ready to handle. The hypervisor (and
> the external VMI toolstack) OTOH should always be in a position to
> handle EPT violations it itself causes by changing the page
> permissions.

Actually, now that I looked at it, that's _exactly_ what we do
already. The suppress_ve bit is always set for all EPT pages. So this
operation here is going to be used to enable #VE for pages, not the
other way around. So there wouldn't be a case of "potentially be #VE
when there should be none".

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits

2019-11-13 Thread Tamas K Lengyel

On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich  wrote:
>
> On 12.11.2019 15:05, Tamas K Lengyel wrote:
> > On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich  wrote:
> >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> >>> +else
> >>> +{
> >>> +rc = p2m_set_suppress_ve_multi(d, _ve);
> >>> +
> >>> +if ( rc == -ERESTART )
> >>> +if ( __copy_field_to_guest(guest_handle_cast(arg,
> >>> +   xen_hvm_altp2m_op_t),
> >>> +   , u.suppress_ve.opaque) )
> >>> +rc = -EFAULT;
> >>
> >> If the operation is best effort, _some_ indication of failure should
> >> still be handed back to the caller. Whether that's through the opaque
> >> field or by some other means is secondary. If not via that field
> >> (which would make the outer of the two if()-s disappear), please fold
> >> the if()-s.
> >
> > At least for mem_sharing_range_op we also do a best-effort and don't
> > return an error for pages where it wasn't possible to share. So I
> > don't think it's absolutely necessary to do that, especially if the
> > caller can't do anything about those errors anyway.
>
> mem-sharing is a little different in nature, isn't it? If you
> can't share a page, both involved guests will continue to run
> with their own instances. If you want to suppress #VE delivery
> and it fails, behavior won't be transparently correct, as
> there'll potentially be #VE when there should be none. Whether
> that's benign to the guest very much depends on its handler.

Makes me wonder whether it would make more sense to flip this thing on
its head and have supress_ve be set by default (since its ignored by
default) and then have pages for which the EPT violation should be
convertible to #VE be specifically enabled by turning suppress_ve off.
That would eliminate the possibility of having the in-guest handler
getting #VE for pages it is not ready to handle. The hypervisor (and
the external VMI toolstack) OTOH should always be in a position to
handle EPT violations it itself causes by changing the page
permissions.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/6] xen: add basic hypervisor filesystem support

2019-11-13 Thread Jan Beulich

On 13.11.2019 15:40, Jürgen Groß wrote:
> On 13.11.19 15:07, Jan Beulich wrote:
>> On 12.11.2019 17:06, Jürgen Groß wrote:
>>> On 12.11.19 14:48, Jan Beulich wrote:
 On 02.10.2019 13:20, Juergen Gross wrote:
> +static unsigned int hypfs_get_entry_len(struct hypfs_entry *entry)
> +{
> +unsigned int len = 0;
> +
> +switch ( entry->type )
> +{
> +case hypfs_type_dir:
> +len = entry->dir->content_size;
> +break;
> +case hypfs_type_string:
> +len = strlen(entry->str_val) + 1;
> +break;
> +case hypfs_type_uint:
> +len = 11;  /* longest possible printed value + 1 */

 Why would uint values be restricted to 32 bits? There are plenty of
 64-bit numbers that might be of interest exposing through this
 interface (and even more so if down the road we were to re-use this
 for something debugfs-like). And even without this I think it would
 be better to not have a literal number here - it'll be close to
 unnoticeable (without someone remembering) when porting to an arch
 with unsigned int wider than 32 bits.
>>>
>>> Support of 64-bit numbers would add "hypfs_type_ulong".
>>
>> At this layer I dislike making assumptions on the bitness of int
>> or long. Can we settle on either a type that's suitable for all
>> sensible values (would likely be unsigned long long) or use fixed
>> with identifications (hypfs_type_u32 et al)?
> 
> This is a problem with e.g. runtime parameters. The current int type
> parameters are unsigned int. So changing the type to hypfs_type_u32
> would then make assumptions about unsigned int bitness.
> 
> My plan was to have hypfs_type_* according to the definitions of the
> variables pointed to. Maybe the sensible way to handle that would be
> to have hypfs_type_u(sz) similar to boot/runtime parameter handling.

Agreed.

> +union {
> +void *content;

 const?

> +struct hypfs_dir *dir;

 const?
>>>
>>> As already said above: mixing const and non-const pointers in a
>>> union looks fishy to me.
>>
>> Hmm, well, I can see your point, but I think it still can be viewed
>> to have its (perhaps largely documentation) value.
> 
> So the void pointer shouldn't be const IMO as it can be used as a
> replacement for all of the other union members.

But this was exactly the reason why I considered it to become
const - to disallow such use when it's about changing a value.

> And the dir member is
> used as non const in case of adding an entry.

Well, if there indeed is such a use (which I had looked for but
apparently overlooked), then of course const shouldn't be added.
Hence the question mark in my initial reply.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [xen-4.12-testing test] 144059: regressions - FAIL

2019-11-13 Thread Jan Beulich

On 13.11.2019 12:55, osstest service owner wrote:
> flight 144059 xen-4.12-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/144059/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. 
> vs. 144035

From looking at this some I get the impression that the L2 guest
is busy-waiting in its boot loader. Seeing that the same test
also failed for 4.11, it doesn't seem entirely impossible that
the fixes for the two XSAs have caused a regression here. Any
other thoughts / insights anyone?

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 5/6] xen: add /buildinfo/config entry to hypervisor filesystem

2019-11-13 Thread Jürgen Groß


On 13.11.19 15:12, Jan Beulich wrote:

On 12.11.2019 17:45, Jürgen Groß wrote:

On 12.11.19 15:22, Jan Beulich wrote:

On 02.10.2019 13:20, Juergen Gross wrote:

@@ -79,3 +80,11 @@ subdir-$(CONFIG_UBSAN) += ubsan
   
   subdir-$(CONFIG_NEEDS_LIBELF) += libelf

   subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
+
+config_data.c: ../.config
+   ( echo "char xen_config_data[] ="; \
+ ../tools/bin2c <$<; \
+ echo ";" ) > $@


Furthermore is there a reason to expose this as plain text, when
Linux exposes a gzip-ed version in /proc? The file isn't very
large now, but this was also the case for Linux many years ago.


gzip data may contain bytes with 0x00. Supporting that would require a
different interface at all levels.


Then perhaps better do so now, when the code is still in flux, than
after the fact, especially if "at all levels" is meant to also
include the public interface?


I'll have a look into that.




--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -25,6 +25,10 @@ static struct hypfs_entry hypfs_root_entry = {
   .dir = _root,
   };
   
+static struct hypfs_dir hypfs_buildinfo = {

+.list = LIST_HEAD_INIT(hypfs_buildinfo.list),
+};
+
   static int hypfs_add_entry(struct hypfs_dir *parent, struct hypfs_entry *new)
   {
   int ret = -ENOENT;
@@ -316,3 +320,16 @@ long do_hypfs_op(unsigned int cmd,
   
   return ret;

   }
+
+static int __init hypfs_init(void)
+{
+int ret;
+
+ret = hypfs_new_dir(_root, "buildinfo", _buildinfo);
+BUG_ON(ret);
+ret = hypfs_new_entry_string(_buildinfo, "config", xen_config_data);
+BUG_ON(ret);
+
+return 0;
+}
+__initcall(hypfs_init);


Hmm, do you really want to centralize population of the file system
here, rather than having the individual components take care of it?


I can add a new source, e.g. common/buildinfo.c if you like that better.


I was rather thinking of moving this into common/kernel.c, next to the
version hypercall handling, and together with exposing the suggested
values here ahead of exposing .config.


Okay.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/6] xen: add basic hypervisor filesystem support

2019-11-13 Thread Jürgen Groß


On 13.11.19 15:07, Jan Beulich wrote:

On 12.11.2019 17:06, Jürgen Groß wrote:

On 12.11.19 14:48, Jan Beulich wrote:

On 02.10.2019 13:20, Juergen Gross wrote:

+static int hypfs_add_entry(struct hypfs_dir *parent, struct hypfs_entry *new)
+{
+int ret = -ENOENT;
+struct list_head *l;
+
+if ( !new->content )
+return -EINVAL;
+
+spin_lock(_lock);
+
+list_for_each ( l, >list )
+{
+struct hypfs_entry *e = list_entry(l, struct hypfs_entry, list);


const?


Hmm, is this true when I add a new entry to it? l is part of *e
after all.


But you don't use e in a way requiring it to be non-const. Question
is (as I did ask elsewhere already) whether you wouldn't better use
list_for_each_entry() here in the first place.


I already agreed on doing that.




+static unsigned int hypfs_get_entry_len(struct hypfs_entry *entry)
+{
+unsigned int len = 0;
+
+switch ( entry->type )
+{
+case hypfs_type_dir:
+len = entry->dir->content_size;
+break;
+case hypfs_type_string:
+len = strlen(entry->str_val) + 1;
+break;
+case hypfs_type_uint:
+len = 11;  /* longest possible printed value + 1 */


Why would uint values be restricted to 32 bits? There are plenty of
64-bit numbers that might be of interest exposing through this
interface (and even more so if down the road we were to re-use this
for something debugfs-like). And even without this I think it would
be better to not have a literal number here - it'll be close to
unnoticeable (without someone remembering) when porting to an arch
with unsigned int wider than 32 bits.


Support of 64-bit numbers would add "hypfs_type_ulong".


At this layer I dislike making assumptions on the bitness of int
or long. Can we settle on either a type that's suitable for all
sensible values (would likely be unsigned long long) or use fixed
with identifications (hypfs_type_u32 et al)?


This is a problem with e.g. runtime parameters. The current int type
parameters are unsigned int. So changing the type to hypfs_type_u32
would then make assumptions about unsigned int bitness.

My plan was to have hypfs_type_* according to the definitions of the
variables pointed to. Maybe the sensible way to handle that would be
to have hypfs_type_u(sz) similar to boot/runtime parameter handling.


So basically something like "(sizeof(type) * 8 * 3 + 9) / 10 + 1" ?
(equivalent to: 10 bits make roughly 3 digits, round that up and
add 0-Byte). This is correct for 1, 2, 4 and 8 byte values. For 16
byte values the result is 40, but it should be 41.


That's one option. The other - especially worthwhile to consider
for large numbers - is to represent them in hex.


Hmm, with your request regarding .config, maybe just transferring the
binary value and size might be the best option.




+break;
+}
+
+return len;
+}
+
+long do_hypfs_op(unsigned int cmd,
+ XEN_GUEST_HANDLE_PARAM(void) arg1, unsigned long arg2,
+ XEN_GUEST_HANDLE_PARAM(void) arg3, unsigned long arg4)
+{
+int ret;
+struct hypfs_entry *entry;
+unsigned int len;
+static char path[XEN_HYPFS_MAX_PATHLEN];
+
+if ( !is_control_domain(current->domain) &&
+ !is_hardware_domain(current->domain) )
+return -EPERM;


Replace by an XSM check?


Yes, but I could need some help here. How do I add a new hypercall
in XSM?


I guess we should rope in Daniel (now Cc-ed).




+spin_lock(_lock);


Wouldn't this better be an r/w lock from the beginning, requiring
only read access here?


Depending on the further use cases we might even end up with per-element
locks. I'm fine using a r/w lock for now.


Indeed I was thinking that write-value support would want a per-entry
lock, with the global one only guarding the directory tree.


+ret = hypfs_get_path_user(path, arg1, arg2);
+if ( ret )
+goto out;
+
+entry = hypfs_get_entry(path);
+if ( !entry )
+{
+ret = -ENOENT;
+goto out;
+}
+
+switch ( cmd )
+{
+case XEN_HYPFS_OP_read_contents:
+{
+char buf[12];
+char *val = buf;


const void *?


Why void *? The result is always a string.


const char * might be fine too, but the code really doesn't depend
on this being other than void afaics.


+ * positive value: content buffer was too small, returned value is needed size


Positive return values are problematic when reaching INT_MAX. Are you
convinced we want to have yet another instance?


Are you convinced we want to return more then 2G long strings in one go?


Counter question: Are you convinced we'll stick to just strings?
See the gzip-ing question on the later patch for example.


Nevertheless I'm questioning the idea to support GB sized buffers. This
seems to be a perfect way to ask for problems.

But with binary value support we'd need a size reported anyway, so this
should be settled then.




+struct hypfs_entry {
+enum hypfs_entry_type type;
+

Re: [Xen-devel] [PATCH for-4.13] xen/passthrough: Render domains with %pd in the 'Q' debug handler

2019-11-13 Thread Jürgen Groß


On 13.11.19 14:44, Andrew Cooper wrote:

IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
quarantined domains.  Use %pd in the printk to render the system
domains more intelligently.

Before:
   (XEN) :00:01.0 - dom 0   - node 0   - MSIs < >
   (XEN) :00:00.0 - dom 0   - node 0   - MSIs < >
   (XEN) :80:00.2 - dom 32754 - node 1   - MSIs < >
   (XEN) :a0:00.2 - dom 32754 - node 1   - MSIs < >
   (XEN) :c0:00.2 - dom 32754 - node 1   - MSIs < >
   (XEN) :e0:00.2 - dom 32754 - node 1   - MSIs < >
   (XEN) :00:00.2 - dom 32754 - node 0   - MSIs < >
   (XEN) :20:00.2 - dom 32754 - node 0   - MSIs < >
   (XEN) :40:00.2 - dom 32754 - node 0   - MSIs < >
   (XEN) :60:00.2 - dom 32754 - node 0   - MSIs < >

After:
   (XEN) :00:01.0 - d0 - node 0   - MSIs < >
   (XEN) :00:00.0 - d0 - node 0   - MSIs < >
   (XEN) :80:00.2 - d[XEN] - node 1   - MSIs < >
   (XEN) :a0:00.2 - d[XEN] - node 1   - MSIs < >
   (XEN) :c0:00.2 - d[XEN] - node 1   - MSIs < >
   (XEN) :e0:00.2 - d[XEN] - node 1   - MSIs < >
   (XEN) :00:00.2 - d[XEN] - node 0   - MSIs < >
   (XEN) :20:00.2 - d[XEN] - node 0   - MSIs < >
   (XEN) :40:00.2 - d[XEN] - node 0   - MSIs < >
   (XEN) :60:00.2 - d[XEN] - node 0   - MSIs < >

Signed-off-by: Andrew Cooper 


Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] AMD/IOMMU: Fix crash in 'V' debugkey

2019-11-13 Thread Jürgen Groß


On 13.11.19 14:41, Andrew Cooper wrote:

c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
for NULL.

intremap_table_entries() internally uses virt_to_page() which falls over

   ASSERT(va >= XEN_VIRT_START);

in __virt_to_page().

Signed-off-by: Andrew Cooper 


Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] AMD/IOMMU: Fix crash in 'V' debugkey

2019-11-13 Thread Jan Beulich

On 13.11.2019 14:41, Andrew Cooper wrote:
> c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
> intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
> for NULL.
> 
> intremap_table_entries() internally uses virt_to_page() which falls over
> 
>   ASSERT(va >= XEN_VIRT_START);
> 
> in __virt_to_page().
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] xen/passthrough: Render domains with %pd in the 'Q' debug handler

2019-11-13 Thread Jan Beulich

On 13.11.2019 14:44, Andrew Cooper wrote:
> IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
> quarantined domains.  Use %pd in the printk to render the system
> domains more intelligently.
> 
> Before:
>   (XEN) :00:01.0 - dom 0   - node 0   - MSIs < >
>   (XEN) :00:00.0 - dom 0   - node 0   - MSIs < >
>   (XEN) :80:00.2 - dom 32754 - node 1   - MSIs < >
>   (XEN) :a0:00.2 - dom 32754 - node 1   - MSIs < >
>   (XEN) :c0:00.2 - dom 32754 - node 1   - MSIs < >
>   (XEN) :e0:00.2 - dom 32754 - node 1   - MSIs < >
>   (XEN) :00:00.2 - dom 32754 - node 0   - MSIs < >
>   (XEN) :20:00.2 - dom 32754 - node 0   - MSIs < >
>   (XEN) :40:00.2 - dom 32754 - node 0   - MSIs < >
>   (XEN) :60:00.2 - dom 32754 - node 0   - MSIs < >
> 
> After:
>   (XEN) :00:01.0 - d0 - node 0   - MSIs < >
>   (XEN) :00:00.0 - d0 - node 0   - MSIs < >
>   (XEN) :80:00.2 - d[XEN] - node 1   - MSIs < >
>   (XEN) :a0:00.2 - d[XEN] - node 1   - MSIs < >
>   (XEN) :c0:00.2 - d[XEN] - node 1   - MSIs < >
>   (XEN) :e0:00.2 - d[XEN] - node 1   - MSIs < >
>   (XEN) :00:00.2 - d[XEN] - node 0   - MSIs < >
>   (XEN) :20:00.2 - d[XEN] - node 0   - MSIs < >
>   (XEN) :40:00.2 - d[XEN] - node 0   - MSIs < >
>   (XEN) :60:00.2 - d[XEN] - node 0   - MSIs < >
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 5/6] xen: add /buildinfo/config entry to hypervisor filesystem

2019-11-13 Thread Jan Beulich

On 12.11.2019 17:45, Jürgen Groß wrote:
> On 12.11.19 15:22, Jan Beulich wrote:
>> On 02.10.2019 13:20, Juergen Gross wrote:
>>> @@ -79,3 +80,11 @@ subdir-$(CONFIG_UBSAN) += ubsan
>>>   
>>>   subdir-$(CONFIG_NEEDS_LIBELF) += libelf
>>>   subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
>>> +
>>> +config_data.c: ../.config
>>> +   ( echo "char xen_config_data[] ="; \
>>> + ../tools/bin2c <$<; \
>>> + echo ";" ) > $@
>>
>> Furthermore is there a reason to expose this as plain text, when
>> Linux exposes a gzip-ed version in /proc? The file isn't very
>> large now, but this was also the case for Linux many years ago.
> 
> gzip data may contain bytes with 0x00. Supporting that would require a
> different interface at all levels.

Then perhaps better do so now, when the code is still in flux, than
after the fact, especially if "at all levels" is meant to also
include the public interface?

>>> --- a/xen/common/hypfs.c
>>> +++ b/xen/common/hypfs.c
>>> @@ -25,6 +25,10 @@ static struct hypfs_entry hypfs_root_entry = {
>>>   .dir = _root,
>>>   };
>>>   
>>> +static struct hypfs_dir hypfs_buildinfo = {
>>> +.list = LIST_HEAD_INIT(hypfs_buildinfo.list),
>>> +};
>>> +
>>>   static int hypfs_add_entry(struct hypfs_dir *parent, struct hypfs_entry 
>>> *new)
>>>   {
>>>   int ret = -ENOENT;
>>> @@ -316,3 +320,16 @@ long do_hypfs_op(unsigned int cmd,
>>>   
>>>   return ret;
>>>   }
>>> +
>>> +static int __init hypfs_init(void)
>>> +{
>>> +int ret;
>>> +
>>> +ret = hypfs_new_dir(_root, "buildinfo", _buildinfo);
>>> +BUG_ON(ret);
>>> +ret = hypfs_new_entry_string(_buildinfo, "config", 
>>> xen_config_data);
>>> +BUG_ON(ret);
>>> +
>>> +return 0;
>>> +}
>>> +__initcall(hypfs_init);
>>
>> Hmm, do you really want to centralize population of the file system
>> here, rather than having the individual components take care of it?
> 
> I can add a new source, e.g. common/buildinfo.c if you like that better.

I was rather thinking of moving this into common/kernel.c, next to the
version hypercall handling, and together with exposing the suggested
values here ahead of exposing .config.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...

2019-11-13 Thread Durrant, Paul

> -Original Message-
> From: Andrew Cooper 
> Sent: 13 November 2019 14:05
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] domain_create: honour global
> grant/maptrack frame limits...
> 
> On 13/11/2019 13:47, Paul Durrant wrote:
> > ...when their values are larger than the per-domain configured limits.
> >
> > Signed-off-by: Paul Durrant 
> > ---
> > After mining through commits it is still unclear to me exactly when Xen
> > stopped honouring the global values, but I really think this commit
> should
> > be back-ported to stable trees as it was a behavioural change that can
> > cause domUs to fail in non-obvious ways.
> 
> -1.  Overriding toolstack settings like this is the same kind of "bad"
> as silently converting HAP => Shadow.
> 
> In particular, this breaks one of points of the original per-domain work
> to deliberately allow stub xenstored to be configured with tiny
> grant/maptrack tables.

Ok, but IMO subtly breaking domUs in the process is not really acceptable 
behaviour.

> 
> You also break the setting of these parameters in xl.conf.

No I don't. xl.conf can still increase values over the command line.

> 
> I'm not defending how the interface changed subtly/unexpected; that was
> bad and we should have done better, but this change is just as bad in
> the opposite direction.
> 
> The way to fix this is to plumb the Xen default parameters though so
> that, in the absence of any explicit configuration (vm.cfg or xl.conf),
> libxl can then use "xen cmdline" as a source of configuration, before
> falling back to hardcoded numbers.
> 

I agree that is the best way to fix it, but not so easy to backport. So my 
proposal (via email a few days ago) was that regressions are fixed immediately 
in this way and then a *proper* fix is done moving forward, which I shall base 
upon Juergen's patches which should allow easy retrieval of the command line 
values.

  Paul

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/6] xen: add basic hypervisor filesystem support

2019-11-13 Thread Jan Beulich

On 12.11.2019 17:06, Jürgen Groß wrote:
> On 12.11.19 14:48, Jan Beulich wrote:
>> On 02.10.2019 13:20, Juergen Gross wrote:
>>> +static int hypfs_add_entry(struct hypfs_dir *parent, struct hypfs_entry 
>>> *new)
>>> +{
>>> +int ret = -ENOENT;
>>> +struct list_head *l;
>>> +
>>> +if ( !new->content )
>>> +return -EINVAL;
>>> +
>>> +spin_lock(_lock);
>>> +
>>> +list_for_each ( l, >list )
>>> +{
>>> +struct hypfs_entry *e = list_entry(l, struct hypfs_entry, list);
>>
>> const?
> 
> Hmm, is this true when I add a new entry to it? l is part of *e
> after all.

But you don't use e in a way requiring it to be non-const. Question
is (as I did ask elsewhere already) whether you wouldn't better use
list_for_each_entry() here in the first place.

>>> +static unsigned int hypfs_get_entry_len(struct hypfs_entry *entry)
>>> +{
>>> +unsigned int len = 0;
>>> +
>>> +switch ( entry->type )
>>> +{
>>> +case hypfs_type_dir:
>>> +len = entry->dir->content_size;
>>> +break;
>>> +case hypfs_type_string:
>>> +len = strlen(entry->str_val) + 1;
>>> +break;
>>> +case hypfs_type_uint:
>>> +len = 11;  /* longest possible printed value + 1 */
>>
>> Why would uint values be restricted to 32 bits? There are plenty of
>> 64-bit numbers that might be of interest exposing through this
>> interface (and even more so if down the road we were to re-use this
>> for something debugfs-like). And even without this I think it would
>> be better to not have a literal number here - it'll be close to
>> unnoticeable (without someone remembering) when porting to an arch
>> with unsigned int wider than 32 bits.
> 
> Support of 64-bit numbers would add "hypfs_type_ulong".

At this layer I dislike making assumptions on the bitness of int
or long. Can we settle on either a type that's suitable for all
sensible values (would likely be unsigned long long) or use fixed
with identifications (hypfs_type_u32 et al)?

> So basically something like "(sizeof(type) * 8 * 3 + 9) / 10 + 1" ?
> (equivalent to: 10 bits make roughly 3 digits, round that up and
> add 0-Byte). This is correct for 1, 2, 4 and 8 byte values. For 16
> byte values the result is 40, but it should be 41.

That's one option. The other - especially worthwhile to consider
for large numbers - is to represent them in hex.

>>> +break;
>>> +}
>>> +
>>> +return len;
>>> +}
>>> +
>>> +long do_hypfs_op(unsigned int cmd,
>>> + XEN_GUEST_HANDLE_PARAM(void) arg1, unsigned long arg2,
>>> + XEN_GUEST_HANDLE_PARAM(void) arg3, unsigned long arg4)
>>> +{
>>> +int ret;
>>> +struct hypfs_entry *entry;
>>> +unsigned int len;
>>> +static char path[XEN_HYPFS_MAX_PATHLEN];
>>> +
>>> +if ( !is_control_domain(current->domain) &&
>>> + !is_hardware_domain(current->domain) )
>>> +return -EPERM;
>>
>> Replace by an XSM check?
> 
> Yes, but I could need some help here. How do I add a new hypercall
> in XSM?

I guess we should rope in Daniel (now Cc-ed).

>>
>>> +spin_lock(_lock);
>>
>> Wouldn't this better be an r/w lock from the beginning, requiring
>> only read access here?
> 
> Depending on the further use cases we might even end up with per-element
> locks. I'm fine using a r/w lock for now.

Indeed I was thinking that write-value support would want a per-entry
lock, with the global one only guarding the directory tree.

>>> +ret = hypfs_get_path_user(path, arg1, arg2);
>>> +if ( ret )
>>> +goto out;
>>> +
>>> +entry = hypfs_get_entry(path);
>>> +if ( !entry )
>>> +{
>>> +ret = -ENOENT;
>>> +goto out;
>>> +}
>>> +
>>> +switch ( cmd )
>>> +{
>>> +case XEN_HYPFS_OP_read_contents:
>>> +{
>>> +char buf[12];
>>> +char *val = buf;
>>
>> const void *?
> 
> Why void *? The result is always a string.

const char * might be fine too, but the code really doesn't depend
on this being other than void afaics.

>>> + * positive value: content buffer was too small, returned value is needed 
>>> size
>>
>> Positive return values are problematic when reaching INT_MAX. Are you
>> convinced we want to have yet another instance?
> 
> Are you convinced we want to return more then 2G long strings in one go?

Counter question: Are you convinced we'll stick to just strings?
See the gzip-ing question on the later patch for example.

>>> +struct hypfs_entry {
>>> +enum hypfs_entry_type type;
>>> +const char *name;
>>> +struct list_head list;
>>> +struct hypfs_dir *parent;
>>
>> Afaict you set this field, but you never use it anywhere. Why do you
>> add it in the first place? (Initially I meant to ask whether this
>> can be pointer-to-const.)
> 
> It will be needed for cases where the entry is being changed, e.g.
> when support for custom runtime parameters is added.

Can we defer its introduction until then?

>>> +union {
>>> +void *content;
>>

Re: [Xen-devel] [PATCH 3/3] xen/mcelog: also allow building for 32-bit kernels

2019-11-13 Thread Jürgen Groß


On 13.11.19 14:47, Jan Beulich wrote:

On 13.11.2019 01:15, Boris Ostrovsky wrote:

On 11/11/19 9:46 AM, Jan Beulich wrote:

There's no apparent reason why it can be used on 64-bit only.

Signed-off-by: Jan Beulich 

--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR
  
  config XEN_MCE_LOG

bool "Xen platform mcelog"
-   depends on XEN_DOM0 && X86_64 && X86_MCE
+   depends on XEN_DOM0 && X86 && X86_MCE


Can we have X86_MCE without X86?


I don't think we can. Is this a request to drop the middle
operand altogether?


I think this would be reasonable. X86_64 was an additional dependency,
while X86 isn't.

With the X86 removed:

Reviewed-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...

2019-11-13 Thread Andrew Cooper

On 13/11/2019 13:47, Paul Durrant wrote:
> ...when their values are larger than the per-domain configured limits.
>
> Signed-off-by: Paul Durrant 
> ---
> After mining through commits it is still unclear to me exactly when Xen
> stopped honouring the global values, but I really think this commit should
> be back-ported to stable trees as it was a behavioural change that can
> cause domUs to fail in non-obvious ways.

-1.  Overriding toolstack settings like this is the same kind of "bad"
as silently converting HAP => Shadow.

In particular, this breaks one of points of the original per-domain work
to deliberately allow stub xenstored to be configured with tiny
grant/maptrack tables.

You also break the setting of these parameters in xl.conf.

I'm not defending how the interface changed subtly/unexpected; that was
bad and we should have done better, but this change is just as bad in
the opposite direction.

The way to fix this is to plumb the Xen default parameters though so
that, in the absence of any explicit configuration (vm.cfg or xl.conf),
libxl can then use "xen cmdline" as a source of configuration, before
falling back to hardcoded numbers.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 13/14] mm/hmm: remove hmm_mirror and related

2019-11-13 Thread Christoph Hellwig

Looks good:

Reviewed-by: Christoph Hellwig 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 03/14] mm/hmm: allow hmm_range to be used with a mmu_interval_notifier or hmm_mirror

2019-11-13 Thread Christoph Hellwig

Looks good,

Reviewed-by: Christoph Hellwig 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 04/14] mm/hmm: define the pre-processor related parts of hmm.h even if disabled

2019-11-13 Thread Christoph Hellwig

Reviewed-by: Christoph Hellwig 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 02/14] mm/mmu_notifier: add an interval tree notifier

2019-11-13 Thread Christoph Hellwig

> +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
> +  struct mm_struct *mm, unsigned long start,
> +  unsigned long length,
> +  const struct mmu_interval_notifier_ops *ops);
> +int mmu_interval_notifier_insert_locked(
> + struct mmu_interval_notifier *mni, struct mm_struct *mm,
> + unsigned long start, unsigned long length,
> + const struct mmu_interval_notifier_ops *ops);

Very inconsistent indentation between these two related functions.

> + /*
> +  * The inv_end incorporates a deferred mechanism like
> +  * rtnl_unlock(). Adds and removes are queued until the final inv_end
> +  * happens then they are progressed. This arrangement for tree updates
> +  * is used to avoid using a blocking lock during
> +  * invalidate_range_start.

Nitpick:  That comment can be condensed into one less line:

/*
 * The inv_end incorporates a deferred mechanism like rtnl_unlock().
 * Adds and removes are queued until the final inv_end happens then
 * they are progressed. This arrangement for tree updates is used to
 * avoid using a blocking lock during invalidate_range_start.
 */

> + /*
> +  * TODO: Since we already have a spinlock above, this would be faster
> +  * as wake_up_q
> +  */
> + if (need_wake)
> + wake_up_all(_mm->wq);

So why is this important enough for a TODO comment, but not important
enough to do right away?

> +  * release semantics on the initialization of the mmu_notifier_mm's
> + * contents are provided for unlocked readers.  acquire can only be
> + * used while holding the mmgrab or mmget, and is safe because once
> + * created the mmu_notififer_mm is not freed until the mm is
> + * destroyed.  As above, users holding the mmap_sem or one of the
> + * mm_take_all_locks() do not need to use acquire semantics.
>*/

Some spaces instead of tabs here.

> +static int __mmu_interval_notifier_insert(
> + struct mmu_interval_notifier *mni, struct mm_struct *mm,
> + struct mmu_notifier_mm *mmn_mm, unsigned long start,
> + unsigned long length, const struct mmu_interval_notifier_ops *ops)

Odd indentation - we usuall do two tabs (my preference) or align after
the opening brace.

> + * This function must be paired with mmu_interval_notifier_insert(). It 
> cannot be

line > 80 chars.

Otherwise this looks good and very similar to what I reviewed earlier:

Reviewed-by: Christoph Hellwig 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...

2019-11-13 Thread Paul Durrant

...when their values are larger than the per-domain configured limits.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 

After mining through commits it is still unclear to me exactly when Xen
stopped honouring the global values, but I really think this commit should
be back-ported to stable trees as it was a behavioural change that can
cause domUs to fail in non-obvious ways.
---
 xen/common/domain.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 66c7fc..aad6d55b82 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -335,6 +335,7 @@ struct domain *domain_create(domid_t domid,
 enum { INIT_watchdog = 1u<<1,
INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
 int err, init_status = 0;
+unsigned int max_grant_frames, max_maptrack_frames;
 
 if ( config && (err = sanitise_domain_config(config)) )
 return ERR_PTR(err);
@@ -456,8 +457,17 @@ struct domain *domain_create(domid_t domid,
 goto fail;
 init_status |= INIT_evtchn;
 
-if ( (err = grant_table_init(d, config->max_grant_frames,
- config->max_maptrack_frames)) != 0 )
+/*
+ * Make sure that the configured values don't reduce any
+ * global command line override.
+ */
+max_grant_frames = max(config->max_grant_frames,
+   opt_max_grant_frames);
+max_maptrack_frames = max(config->max_maptrack_frames,
+  opt_max_maptrack_frames);
+
+if ( (err = grant_table_init(d, max_grant_frames,
+ max_maptrack_frames)) != 0 )
 goto fail;
 init_status |= INIT_gnttab;
 
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 01/14] mm/mmu_notifier: define the header pre-processor parts even if disabled

2019-11-13 Thread Christoph Hellwig

Looks good,

Reviewed-by: Christoph Hellwig 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...

2019-11-13 Thread Durrant, Paul

Sorry, the Cc list got dropped... I'll re-send.

  Paul

> -Original Message-
> From: Paul Durrant 
> Sent: 13 November 2019 13:47
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul 
> Subject: [PATCH] domain_create: honour global grant/maptrack frame
> limits...
> 
> ...when their values are larger than the per-domain configured limits.
> 
> Signed-off-by: Paul Durrant 
> ---
> After mining through commits it is still unclear to me exactly when Xen
> stopped honouring the global values, but I really think this commit should
> be back-ported to stable trees as it was a behavioural change that can
> cause domUs to fail in non-obvious ways.
> ---
>  xen/common/domain.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 66c7fc..aad6d55b82 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -335,6 +335,7 @@ struct domain *domain_create(domid_t domid,
>  enum { INIT_watchdog = 1u<<1,
> INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
>  int err, init_status = 0;
> +unsigned int max_grant_frames, max_maptrack_frames;
> 
>  if ( config && (err = sanitise_domain_config(config)) )
>  return ERR_PTR(err);
> @@ -456,8 +457,17 @@ struct domain *domain_create(domid_t domid,
>  goto fail;
>  init_status |= INIT_evtchn;
> 
> -if ( (err = grant_table_init(d, config->max_grant_frames,
> - config->max_maptrack_frames)) != 0 )
> +/*
> + * Make sure that the configured values don't reduce any
> + * global command line override.
> + */
> +max_grant_frames = max(config->max_grant_frames,
> +   opt_max_grant_frames);
> +max_maptrack_frames = max(config->max_maptrack_frames,
> +  opt_max_maptrack_frames);
> +
> +if ( (err = grant_table_init(d, max_grant_frames,
> + max_maptrack_frames)) != 0 )
>  goto fail;
>  init_status |= INIT_gnttab;
> 
> --
> 2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] AMD/IOMMU: restore DTE fields in amd_iommu_setup_domain_device()

2019-11-13 Thread Jan Beulich

Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
allocation") moved ourselves into a more secure default state, but
didn't take sufficient care to also undo the effects when handing a
previously disabled device back to a(nother) domain. Put the fields
that may have been changed elsewhere back to their intended values
(some fields amd_iommu_disable_domain_device() touches don't
currently get written anywhere else, and hence don't need modifying
here).

Reported-by: Sander Eikelenboom 
Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -114,11 +114,21 @@ static void amd_iommu_setup_domain_devic
 
 if ( !dte->v || !dte->tv )
 {
+const struct ivrs_mappings *ivrs_dev;
+
 /* bind DTE to domain page-tables */
 amd_iommu_set_root_page_table(
 dte, page_to_maddr(hd->arch.root_table), domain->domain_id,
 hd->arch.paging_mode, valid);
 
+/* Undo what amd_iommu_disable_domain_device() may have done. */
+ivrs_dev = _ivrs_mappings(iommu->seg)[req_id];
+if ( dte->it_root )
+dte->int_ctl = IOMMU_DEV_TABLE_INT_CONTROL_TRANSLATED;
+dte->iv = iommu_intremap;
+dte->ex = ivrs_dev->dte_allow_exclusion;
+dte->sys_mgt = MASK_EXTR(ivrs_dev->device_flags, 
ACPI_IVHD_SYSTEM_MGMT);
+
 if ( pci_ats_device(iommu->seg, bus, pdev->devfn) &&
  iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
 dte->i = ats_enabled;

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...

2019-11-13 Thread Paul Durrant

...when their values are larger than the per-domain configured limits.

Signed-off-by: Paul Durrant 
---
After mining through commits it is still unclear to me exactly when Xen
stopped honouring the global values, but I really think this commit should
be back-ported to stable trees as it was a behavioural change that can
cause domUs to fail in non-obvious ways.
---
 xen/common/domain.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 66c7fc..aad6d55b82 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -335,6 +335,7 @@ struct domain *domain_create(domid_t domid,
 enum { INIT_watchdog = 1u<<1,
INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
 int err, init_status = 0;
+unsigned int max_grant_frames, max_maptrack_frames;
 
 if ( config && (err = sanitise_domain_config(config)) )
 return ERR_PTR(err);
@@ -456,8 +457,17 @@ struct domain *domain_create(domid_t domid,
 goto fail;
 init_status |= INIT_evtchn;
 
-if ( (err = grant_table_init(d, config->max_grant_frames,
- config->max_maptrack_frames)) != 0 )
+/*
+ * Make sure that the configured values don't reduce any
+ * global command line override.
+ */
+max_grant_frames = max(config->max_grant_frames,
+   opt_max_grant_frames);
+max_maptrack_frames = max(config->max_maptrack_frames,
+  opt_max_maptrack_frames);
+
+if ( (err = grant_table_init(d, max_grant_frames,
+ max_maptrack_frames)) != 0 )
 goto fail;
 init_status |= INIT_gnttab;
 
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/mcelog: also allow building for 32-bit kernels

2019-11-13 Thread Jan Beulich

On 13.11.2019 01:15, Boris Ostrovsky wrote:
> On 11/11/19 9:46 AM, Jan Beulich wrote:
>> There's no apparent reason why it can be used on 64-bit only.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/drivers/xen/Kconfig
>> +++ b/drivers/xen/Kconfig
>> @@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR
>>  
>>  config XEN_MCE_LOG
>>  bool "Xen platform mcelog"
>> -depends on XEN_DOM0 && X86_64 && X86_MCE
>> +depends on XEN_DOM0 && X86 && X86_MCE
> 
> Can we have X86_MCE without X86?

I don't think we can. Is this a request to drop the middle
operand altogether?

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] AMD/IOMMU: Fix crash in 'V' debugkey

2019-11-13 Thread Andrew Cooper

On 13/11/2019 13:41, Andrew Cooper wrote:
> c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
> intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
> for NULL.
>
> intremap_table_entries() internally uses virt_to_page() which falls over
>
>   ASSERT(va >= XEN_VIRT_START);
>
> in __virt_to_page().
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Juergen Gross 
>
> For 4.13.  Regression vs 4.12

Oops sorry.  Should have had a Reported-by: Igor Druzhinin


Fixed up locally

~Andrew

> ---
>  xen/drivers/passthrough/amd/iommu_intr.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/xen/drivers/passthrough/amd/iommu_intr.c 
> b/xen/drivers/passthrough/amd/iommu_intr.c
> index 1eed60f265..5e92c023f8 100644
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -847,11 +847,13 @@ static void dump_intremap_table(const struct amd_iommu 
> *iommu,
>  union irte_cptr tbl,
>  const struct ivrs_mappings *ivrs_mapping)
>  {
> -unsigned int count, nr = intremap_table_entries(tbl.ptr, iommu);
> +unsigned int count, nr;
>  
>  if ( !tbl.ptr )
>  return;
>  
> +nr = intremap_table_entries(tbl.ptr, iommu);
> +
>  for ( count = 0; count < nr; count++ )
>  {
>  if ( iommu->ctrl.ga_en


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/3] xen/mcelog: add PPIN to record when available

2019-11-13 Thread Jan Beulich

On 13.11.2019 01:11, Boris Ostrovsky wrote:
> On 11/11/19 9:46 AM, Jan Beulich wrote:
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -393,6 +393,8 @@
>>  #define MSR_AMD_PSTATE_DEF_BASE 0xc0010064
>>  #define MSR_AMD64_OSVW_ID_LENGTH0xc0010140
>>  #define MSR_AMD64_OSVW_STATUS   0xc0010141
>> +#define MSR_AMD_PPIN_CTL0xc00102f0
>> +#define MSR_AMD_PPIN0xc00102f1
> 
> Which processors are these defined for? I looked at a couple (fam 15h
> and 17h) and didn't see those. And I don't see them in Linux.

Certain Fam17 ones, Rome in particular (which is where I've
tested this).

>> --- a/include/xen/interface/xen-mca.h
>> +++ b/include/xen/interface/xen-mca.h
>> @@ -332,7 +332,11 @@ struct xen_mc {
>>  };
>>  DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
>>  
>> -/* Fields are zero when not available */
>> +/*
>> + * Fields are zero when not available. Also, this struct is shared with
>> + * userspace mcelog and thus must keep existing fields at current offsets.
>> + * Only add new fields to the end of the structure
>> + */
>>  struct xen_mce {
> 
> Why is this structure is part of the interface?

That's a question to whoever put it there. There look to have
been decisions (see also patch 1) to have the Linux clones of
Xen's public headers deviate far more from their original
than I would consider reasonable.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13] xen/passthrough: Render domains with %pd in the 'Q' debug handler

2019-11-13 Thread Andrew Cooper

IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
quarantined domains.  Use %pd in the printk to render the system
domains more intelligently.

Before:
  (XEN) :00:01.0 - dom 0   - node 0   - MSIs < >
  (XEN) :00:00.0 - dom 0   - node 0   - MSIs < >
  (XEN) :80:00.2 - dom 32754 - node 1   - MSIs < >
  (XEN) :a0:00.2 - dom 32754 - node 1   - MSIs < >
  (XEN) :c0:00.2 - dom 32754 - node 1   - MSIs < >
  (XEN) :e0:00.2 - dom 32754 - node 1   - MSIs < >
  (XEN) :00:00.2 - dom 32754 - node 0   - MSIs < >
  (XEN) :20:00.2 - dom 32754 - node 0   - MSIs < >
  (XEN) :40:00.2 - dom 32754 - node 0   - MSIs < >
  (XEN) :60:00.2 - dom 32754 - node 0   - MSIs < >

After:
  (XEN) :00:01.0 - d0 - node 0   - MSIs < >
  (XEN) :00:00.0 - d0 - node 0   - MSIs < >
  (XEN) :80:00.2 - d[XEN] - node 1   - MSIs < >
  (XEN) :a0:00.2 - d[XEN] - node 1   - MSIs < >
  (XEN) :c0:00.2 - d[XEN] - node 1   - MSIs < >
  (XEN) :e0:00.2 - d[XEN] - node 1   - MSIs < >
  (XEN) :00:00.2 - d[XEN] - node 0   - MSIs < >
  (XEN) :20:00.2 - d[XEN] - node 0   - MSIs < >
  (XEN) :40:00.2 - d[XEN] - node 0   - MSIs < >
  (XEN) :60:00.2 - d[XEN] - node 0   - MSIs < >

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Juergen Gross 

4.13 nice-to-have.  Not strictly required, but it is a low risk change which
improves diagnostics.
---
 xen/drivers/passthrough/pci.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 18a7dc7224..8e501a79a8 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1349,10 +1349,9 @@ static int _dump_pci_devices(struct pci_seg *pseg, void 
*arg)
 
 list_for_each_entry ( pdev, >alldevs_list, alldevs_list )
 {
-printk("%04x:%02x:%02x.%u - dom %-3d - node %-3d - MSIs < ",
+printk("%04x:%02x:%02x.%u - %pd - node %-3d - MSIs < ",
pseg->nr, pdev->bus,
-   PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),
-   pdev->domain ? pdev->domain->domain_id : -1,
+   PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), pdev->domain,
(pdev->node != NUMA_NO_NODE) ? pdev->node : -1);
 list_for_each_entry ( msi, >msi_list, list )
printk("%d ", msi->irq);
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13] AMD/IOMMU: Fix crash in 'V' debugkey

2019-11-13 Thread Andrew Cooper

c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
for NULL.

intremap_table_entries() internally uses virt_to_page() which falls over

  ASSERT(va >= XEN_VIRT_START);

in __virt_to_page().

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Juergen Gross 

For 4.13.  Regression vs 4.12
---
 xen/drivers/passthrough/amd/iommu_intr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/amd/iommu_intr.c 
b/xen/drivers/passthrough/amd/iommu_intr.c
index 1eed60f265..5e92c023f8 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -847,11 +847,13 @@ static void dump_intremap_table(const struct amd_iommu 
*iommu,
 union irte_cptr tbl,
 const struct ivrs_mappings *ivrs_mapping)
 {
-unsigned int count, nr = intremap_table_entries(tbl.ptr, iommu);
+unsigned int count, nr;
 
 if ( !tbl.ptr )
 return;
 
+nr = intremap_table_entries(tbl.ptr, iommu);
+
 for ( count = 0; count < nr; count++ )
 {
 if ( iommu->ctrl.ga_en
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] x86/boot: Remove cached CPUID data from the trampoline

2019-11-13 Thread Jan Beulich

On 13.11.2019 14:22, Andrew Cooper wrote:
> I am not convinced the behaviour is worth changing, and I don't have
> time for this scope creep.

There's no scope creep here at all. All I'm asking for is that you
don't blindly OR in EFER_NX into trampoline_efer, but rather check
that it will be possible to successfully set it after the
MISC_ENABLE write (by reading back the value, or by reading
CPUID[0x8001].NX again).

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] x86/boot: Remove cached CPUID data from the trampoline

2019-11-13 Thread Andrew Cooper

On 12/11/2019 17:15, Jan Beulich wrote:
> On 12.11.2019 17:09, Andrew Cooper wrote:
>> On 04/11/2019 15:31, Jan Beulich wrote:
>>> On 04.11.2019 16:22, Andrew Cooper wrote:
 On 04/11/2019 15:03, Jan Beulich wrote:
> On 04.11.2019 15:59, Andrew Cooper wrote:
>> On 04/11/2019 13:25, Jan Beulich wrote:
>>> On 01.11.2019 21:25, Andrew Cooper wrote:
 --- a/xen/arch/x86/cpu/intel.c
 +++ b/xen/arch/x86/cpu/intel.c
 @@ -270,6 +270,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
if (disable) {
wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable & ~disable);
bootsym(trampoline_misc_enable_off) |= disable;
 +  bootsym(trampoline_efer) |= EFER_NX;
}
>>> I'm fine with all other changes here, just this one concerns me:
>>> Before your change we latch a value into trampoline_misc_enable_off
>>> just to be used for subsequent IA32_MISC_ENABLE writes we do. This
>>> means that, on a hypervisor (like Xen itself) simply discarding
>>> guest writes to the MSR (which is "fine" with the described usage
>>> of ours up to now), with your change we'd now end up trying to set
>>> EFER.NX when the feature may not actually be enabled in
>>> IA32_MISC_ENABLE. Wouldn't such an EFER write be liable to #GP(0)?
>>> I.e. don't we need to read back the MSR value here, and verify
>>> we actually managed to clear the bit before actually OR-ing in
>>> EFER_NX?
>> If this is a problem in practice, execution won't continue beyond the
>> next if() condition just out of context, which set EFER.NX on the BSP
>> with an unguarded WRMSR.
> And how is this any good? This kind of crash is exactly what I'm
> asking to avoid.
 What is the point of working around a theoretical edge case of broken
 nesting under Xen which demonstrably doesn't exist in practice?
>>> Well, so far nothing was said about this not being an actual problem.
>> Its not an actual problem.  If it were, we would have had crash reports.
>>
>>> I simply don't know whether hardware would refuse such an EFER write.
>> I've just experimented - writing EFER.NX takes a #GP fault when
>> MISC_ENABLE.XD is set.
>>
>>> If it does, it would be appropriate for hypervisors to also refuse
>>> it. I.e. if we don't do so right now, correcting the behavior would
>>> trip the code here.
>> MISC_ENABLES.XD is architectural on any Intel system which enumerates
>> NX, and if the bit is set, it can be cleared.  (Although the semantics
>> described in the SDM are broken.  It is only available if NX is
>> enumerated, which is obfuscated by setting XD).
>>
>> However, no hypervisor is going to bother virtualising this
>> functionality.  Either configure the VM with NX or without.  (KVM for
>> example doesn't virtualise MISC_ENABLES at all.)
> I'm sorry, but I still don't follow: You say "if the bit is set, it
> can be cleared", which is clearly not in line with our current guest
> MSR write handling.

Yes - Xen's MSR handing is broken, but you snipped that part of my reply.

> It just so happens that we have no command line
> option allowing to suppress the clearing of XD.

Nor does Linux.  As to the other hypervisors...

> If we had, according
> to your findings above we'd run into a #GP upon trying to set NX.

Yes.

> How can you easily exclude another hypervisor actually doing so (and
> nobody having run into the issue simply because the option is rarely
> used)?

... observe that they require NX support as a prerequisite to install. 
You will not find a system with XD set these days.

> Btw - all would be fine if the code in question was guarded by an
> NX feature check, but as you say that's not possible because XD set
> forces NX clear. However, our setting of EFER.NX could be guarded
> this way, as we _expect_ XD to be clear at that point.

XD was clearly never designed for the OS to find and turn off, but NX
functionality is simply too important to let misconfigured firmware get
in the way of using.


The long and the short of it is that this patch does not change Xen's
behaviour WRT poorly virtualised XD.

I am not convinced the behaviour is worth changing, and I don't have
time for this scope creep.  If you want to submit a fix then go ahead,
but patch 3 of this is important to get in for 4.13

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [libvirt test] 144071: regressions - FAIL

2019-11-13 Thread osstest service owner

flight 144071 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144071/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 143023
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 143023
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 143023
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 143023

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  9cd03f7957e114892ae54e7ccb3758b6fb440644
baseline version:
 libvirt  2cff65e4c60ed7b3c0c6a97d526d1f8d52c0e919

Last test of basis   143023  2019-10-22 04:19:26 Z   22 days
Failing since143051  2019-10-23 04:18:57 Z   21 days   18 attempts
Testing same since   144071  2019-11-13 04:19:29 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Andrew Jones 
  Bjoern Walk 
  Daniel Henrique Barboza 
  Daniel P. Berrangé 
  Daniel Veillard 
  Eric Blake 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Laine Stump 
  Mao Zhongyi 
  Maya Rashish 
  Michal Privoznik 
  Pavel Hrdina 
  Peter Krempa 
  Wang Yechao 
  Yi Li 
  Zhang Shengju 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master

[Xen-devel] [xen-4.12-testing test] 144059: regressions - FAIL

2019-11-13 Thread osstest service owner

flight 144059 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144059/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
144035

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow217 guest-localmigrate/x10   fail  like 144007
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  0138da196c8c334589a25144d4d69bf6553e2658
baseline version:
 xen  278e46ae8f99485915ae662e7905c8333a55048a

Last test of basis   144035  2019-11-12 00:36:50 Z1 days
Testing same since   144059  2019-11-12 19:10:11 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 

jobs:

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

2019-11-13 Thread osstest service owner

flight 144075 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144075/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  8c4330818f6ee70cbf7428a40a28a73df1272d10
baseline version:
 xen  a458d3bd0d2585275c128556ec0cbd818c6a7b0d

Last test of basis   143616  2019-11-03 09:24:51 Z   10 days
Testing same since   144075  2019-11-13 09:19:05 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Anthony PERARD 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Marek Marczykowski-Górecki 
  Paul Durrant 
  Roger Pau Monné 
  Stefano Stabellini 
  Stewart Hildebrand 
  Wei Liu 

jobs:
 coverity-amd64   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   a458d3bd0d..8c4330818f  8c4330818f6ee70cbf7428a40a28a73df1272d10 -> 
coverity-tested/smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.11-testing test] 144058: regressions - FAIL

2019-11-13 Thread osstest service owner

flight 144058 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144058/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
144025

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  74507046dbd2c5d2991eeabd1af39af0d6b29d70
baseline version:
 xen  006b2041242129896fbd30135b3dc6f575894a07

Last test of basis   144025  2019-11-11 17:36:00 Z1 days
Testing same since   144058  2019-11-12 18:05:56 Z0 days1 attempts

78 matches

Mail list logo