[libvirt test] 163588: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  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-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   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-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  11fcf054e6778e977ea82baa10db9ee7a197d4f6
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  367 days
Failing since151818  2020-07-11 04:18:52 Z  366 days  358 attempts
Testing same since   163510  2021-07-10 04:20:02 Z2 days3 attempts


People who touched revisions under test:
Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Aleksei Zakharov 
  Andika Triwidada 
  Andrea Bolognani 
  Balázs Meskó 
  Barrett Schonefeld 
  Bastian Germann 
  Bastien Orivel 
  BiaoXiang Ye 
  Bihong Yu 
  Binfeng Wu 
  Bjoern Walk 
  Boris Fiuczynski 
  Brian Turek 
  Bruno Haible 
  Chris Mayo 
  Christian Ehrhardt 
  Christian Schoenebeck 
  Cole Robinson 
  Collin Walling 
  Cornelia Huck 
  Cédric Bosdonnat 
  Côme Borsoi 
  Daniel Henrique Barboza 
  Daniel Letai 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  Didik Supriadi 
  Dmytro Linkin 
  Eiichi Tsukata 
  Eric Farman 
  Erik Skultety 
  Fabian Affolter 
  Fabian Freyer 
  Fabiano Fidêncio 
  Fangge Jin 
  Farhan Ali 
  Fedora Weblate Translation 
  gongwei 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Hela Basa 
  Helmut Grohne 
  Ian Wienand 
  Jakob Meng 
  Jamie Strandboge 
  Jamie Strandboge 
  Jan Kuparinen 
  Jean-Baptiste Holcroft 
  Jianan Gao 
  Jim Fehlig 
  Jin Yan 
  Jiri Denemark 
  John Ferlan 
  Jonathan Watt 
  Jonathon Jongsma 
  Julio Faracco 
  Ján Tomko 
  Kashyap Chamarthy 
  Kevin Locke 
  Kristina Hanicova 
  Laine Stump 
  Laszlo Ersek 
  Lee Yarwood 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Lin Ma 
  Liu Yiding 
  Luke Yue 
  Luyao Zhong 
  Marc Hartmayer 
  Marc-André Lureau 
  Marek Marczykowski-Górecki 
  Markus Schade 
  Martin Kletzander 
  Masayoshi Mizuma 
  Matt Coleman 
  Matt Coleman 
  Mauro Matteo Cascella 
  Meina Li 
  Michal Privoznik 
  Michał Smyk 
  Milo Casagrande 
  Moshe Levi 
  Muha Aliss 
  Nathan 
  Neal Gompa 
  Nick Shyrokovskiy 
  Nickys Music Group 
  Nico Pache 
  Nikolay Shirokovskiy 
  Olaf Hering 
  Olesya Gerasimenko 
  Orion Poplawski 
  Pany 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  Peng Liang 
  Peter Krempa 
  Pino Toscano 
  Pino Toscano 
  Piotr Drąg 
  Prathamesh Chavan 
  Ricky Tigg 
  Roman Bogorodskiy 
  Roman Bolshakov 
  Ryan Gahagan 
  Ryan Schmidt 
  Sam Hartman 
  Scott Shambarger 
  Sebastian Mitterle 
  SeongHyun Jo 
  Shalini Chellathurai Saroja 
  Shaojun Yang 
  Shi Lei 
  simmon 
  Simon Chopin 
  Simon Gaiser 
  Stefan Bader 
  Stefan Berger 
  Stefan Berger 
  Stefan Hajnoczi 
  Szymon Scholz 
  Thomas Huth 
  Tim Wiederhake 
  Tomáš Golembiovský 
  Tomáš Janoušek 
  Tuguoyi 
  Ville Skyttä 
  Vinayak Kale 
  Wang Xin 
  WangJian 
  Weblate 
  Wei Liu 
  Wei Liu 
  William Douglas 
  Yalei Li <274268...@qq.com>
  Yalei Li 
  Yang Hang 
  Yanqiu Zhang 
  Yaroslav Kargin 
  Yi Li 
  Yi Wang 
  Yuri Chornoivan 
  Zbigniew Jędrzejewski-Szmek 
  Zheng Chuan 
  zhenwei pi 
  Zhenyu Zheng 

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

[linux-linus test] 163573: regressions - FAIL

[osstest service owner]

flight 163573 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163573/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-examine   6 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332
 test-amd64-i386-libvirt   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-i386-xl7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-freebsd10-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-raw7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-pvshim 7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-shadow 7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-freebsd10-i386  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-coresched-i386-xl  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt-xsm   7 xen-install  fail REGR. vs. 152332
 test-amd64-amd64-libvirt-vhd 13 guest-start  fail REGR. vs. 152332
 test-arm64-arm64-xl-credit1  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl-credit2  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl-xsm  13 debian-fixup fail REGR. vs. 152332
 test-amd64-amd64-amd64-pvgrub 20 guest-stop  fail REGR. vs. 152332
 test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl  13 debian-fixup fail REGR. vs. 152332
 test-amd64-amd64-i386-pvgrub 20 guest-stop   fail REGR. vs. 152332
 test-armhf-armhf-xl   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-libvirt  8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-libvirt-raw  8 xen-boot fail REGR. vs. 152332
 test-amd64-amd64-xl-qcow213 guest-start  fail REGR. vs. 152332
 test-armhf-armhf-xl-multivcpu  8 xen-bootfail REGR. vs. 152332
 test-armhf-armhf-xl-credit2   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl-credit1   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl-vhd  13 guest-start  fail REGR. vs. 152332
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 152332
 test-armhf-armhf-xl-arndale   8 xen-boot fail REGR. vs. 152332
 test-arm64-arm64-libvirt-xsm 14 guest-startfail in 163556 REGR. vs. 152332

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-examine4 memdisk-try-append fail in 163556 pass in 163573
 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 163556
 test-arm64-arm64-libvirt-xsm 13 debian-fixup   fail pass in 163556

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  8 xen-boot fail REGR. vs. 152332

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332
 test-amd64-amd64-xl-qemuu-win7-a

Re: [PATCH v2] xen/arm64: Remove READ/WRITE_SYSREG32 helper macros

[Julien Grall]

On 12/07/2021 07:26, Michal Orzel wrote:

Hi Julien,


Hi Michal,


On 09.07.2021 17:21, Julien Grall wrote:

Hi Michal,

On 09/07/2021 13:40, Michal Orzel wrote:

AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.

The last place in code making use of READ/WRITE_SYSREG32
on arm64 is in TVM_REG macro defining functions vreg_emulate_.
Implement a macro WRITE_SYSREG_SZ which expands as follows:
-on arm64: WRITE_SYSREG
-on arm32: WRITE_SYSREG{32/64}

As there are no other places in the code using these helpers
on arm64 - remove them.

Signed-off-by: Michal Orzel 
---
Changes since v1:
-implement WRITE_SYSREG_SZ instead of duplicating the TVM_REG
---
   xen/arch/arm/vcpreg.c   | 12 +++-
   xen/include/asm-arm/arm64/sysregs.h |  4 
   2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index f0cdcc8a54..10c4846954 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -47,6 +47,16 @@
    *
    */
   +#ifdef CONFIG_ARM_64
+#define WRITE_SYSREG_SZ(sz, val, sysreg) WRITE_SYSREG(val, sysreg)


I think you want to cast to (uint##sz##_t) to avoid any surprise. I think...


But the val will always be of type uint##sz##_t because it is passed from ...

+#else
+/*
+ * WRITE_SYSREG{32/64} on arm32 is defined as variadic macro which imposes
+ * on the below macro to be defined like that as well.
+ */
+#define WRITE_SYSREG_SZ(sz, val, sysreg...)  WRITE_SYSREG##sz(val, sysreg)
+#endif
+
   /* The name is passed from the upper macro to workaround macro expansion. */
   #define TVM_REG(sz, func, reg...)   \
   static bool func(struct cpu_user_regs *regs, uint##sz##_t *r, bool read)    \
@@ -55,7 +65,7 @@ static bool func(struct cpu_user_regs *regs, uint##sz##_t *r, 
bool read)    \

... here(*r argument).
So I do not think that such casting makes sense e.g
uint##sz##_t foo;
WRITE_SYSREG((uint##sz##_t)foo, bar);


I agree that this doesn't make sense for the *current* use. However, 
when writing code, we need to think how one could use it in the future...


When I read the name, I would expect that if I call it with sz == 32, 
then bottom 32-bit value to be written and the top 32-bit zeroed. But 
this is not the case...


You are relying on the developper and reviewer to notice that only 
32-bit value should be passed when sz == 32.


I am not particularly keen on relying on this when a simple cast could 
prevent any future misuse. Alternatively, I would be happy to consider 
checking the type of the value at build time.


Cheers,

--
Julien Grall

Re: [PATCH v2 1/2] tools/xenstore: set oom score for xenstore daemon on Linux

[Julien Grall]

Hi Juergen,

On 09/07/2021 13:34, Juergen Gross wrote:

On 08.07.21 19:40, Julien Grall wrote:

Hi Juergen,

On 08/06/2021 06:58, Juergen Gross wrote:

Xenstored is absolutely mandatory for a Xen host and it can't be
restarted, so being killed by OOM-killer in case of memory shortage is
to be avoided.

Set /proc/$pid/oom_score_adj (if available) to -500 in order to allow
xenstored to use large amounts of memory without being killed.

Make sure the pid file isn't a left-over from a previous run delete it
before starting xenstored.


This sentence is a bit confusing to read. Do you mean "*To* make 
sure*,* delete it before"?


Yes, will change it.





Signed-off-by: Juergen Gross 
---
V2:
- set oom score from launch script (Julien Grall)
- split off open file descriptor limit setting (Julien Grall)
---
  tools/hotplug/Linux/launch-xenstore.in | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/tools/hotplug/Linux/launch-xenstore.in 
b/tools/hotplug/Linux/launch-xenstore.in

index 019f9d6f4d..3ad71e3d08 100644
--- a/tools/hotplug/Linux/launch-xenstore.in
+++ b/tools/hotplug/Linux/launch-xenstore.in
@@ -59,11 +59,14 @@ test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons 
&& . @CONFIG_DIR@/@CONFIG_LEAF

  echo "No xenstored found"
  exit 1
  }
+    rm -f @XEN_RUN_DIR@/xenstored.pid
  echo -n Starting $XENSTORED...
  $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS
  systemd-notify --booted 2>/dev/null || timeout_xenstore 
$XENSTORED || exit 1

+    XS_PID=`cat @XEN_RUN_DIR@/xenstored.pid`
+    echo -500 >/proc/$XS_PID/oom_score_adj


NIT: It would be worth considering to introduce a variable so this can 
be set from the configuration file.


Do you have any scenario in mind where this would be beneficial?

I'm not against it, but I'm wondering why anybody would want that
to be configurable.


So from the commit message (and browsing a bit), I don't understand how 
-500 would fit every case. IOW why not -600/-700...?


If it is a random value, then we should consider to allow the user to 
modify it easily. If the value has a specific meaning, then I think this 
ought to be written in the commit message and possibly launch-xenstore.in.


Cheers,

--
Julien Grall

Re: [PATCH v2] xen/arm64: Remove READ/WRITE_SYSREG32 helper macros

[Michal Orzel]

On 12.07.2021 10:33, Julien Grall wrote:
> 
> 
> On 12/07/2021 07:26, Michal Orzel wrote:
>> Hi Julien,
> 
> Hi Michal,
> 
>> On 09.07.2021 17:21, Julien Grall wrote:
>>> Hi Michal,
>>>
>>> On 09/07/2021 13:40, Michal Orzel wrote:
 AArch64 system registers are 64bit whereas AArch32 ones
 are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
 we should get rid of helpers READ/WRITE_SYSREG32
 in favour of using READ/WRITE_SYSREG.

 The last place in code making use of READ/WRITE_SYSREG32
 on arm64 is in TVM_REG macro defining functions vreg_emulate_.
 Implement a macro WRITE_SYSREG_SZ which expands as follows:
 -on arm64: WRITE_SYSREG
 -on arm32: WRITE_SYSREG{32/64}

 As there are no other places in the code using these helpers
 on arm64 - remove them.

 Signed-off-by: Michal Orzel 
 ---
 Changes since v1:
 -implement WRITE_SYSREG_SZ instead of duplicating the TVM_REG
 ---
    xen/arch/arm/vcpreg.c   | 12 +++-
    xen/include/asm-arm/arm64/sysregs.h |  4 
    2 files changed, 11 insertions(+), 5 deletions(-)

 diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
 index f0cdcc8a54..10c4846954 100644
 --- a/xen/arch/arm/vcpreg.c
 +++ b/xen/arch/arm/vcpreg.c
 @@ -47,6 +47,16 @@
     *
     */
    +#ifdef CONFIG_ARM_64
 +#define WRITE_SYSREG_SZ(sz, val, sysreg) WRITE_SYSREG(val, sysreg)
>>>
>>> I think you want to cast to (uint##sz##_t) to avoid any surprise. I think...
>>>
>> But the val will always be of type uint##sz##_t because it is passed from ...
 +#else
 +/*
 + * WRITE_SYSREG{32/64} on arm32 is defined as variadic macro which imposes
 + * on the below macro to be defined like that as well.
 + */
 +#define WRITE_SYSREG_SZ(sz, val, sysreg...)  WRITE_SYSREG##sz(val, sysreg)
 +#endif
 +
    /* The name is passed from the upper macro to workaround macro 
 expansion. */
    #define TVM_REG(sz, func, reg...)   
     \
    static bool func(struct cpu_user_regs *regs, uint##sz##_t *r, bool 
 read)    \
 @@ -55,7 +65,7 @@ static bool func(struct cpu_user_regs *regs, 
 uint##sz##_t *r, bool read)    \
>> ... here(*r argument).
>> So I do not think that such casting makes sense e.g
>> uint##sz##_t foo;
>> WRITE_SYSREG((uint##sz##_t)foo, bar);
> 
> I agree that this doesn't make sense for the *current* use. However, when 
> writing code, we need to think how one could use it in the future...
> 
> When I read the name, I would expect that if I call it with sz == 32, then 
> bottom 32-bit value to be written and the top 32-bit zeroed. But this is not 
> the case...
> 
> You are relying on the developper and reviewer to notice that only 32-bit 
> value should be passed when sz == 32.
> 
> I am not particularly keen on relying on this when a simple cast could 
> prevent any future misuse. Alternatively, I would be happy to consider 
> checking the type of the value at build time.
> 
> Cheers,
> 

Ok, you are right that it does not cost much to add it, so let's stick with:
#ifdef CONFIG_ARM_64
#define WRITE_SYSREG_SZ(sz, val, sysreg) WRITE_SYSREG((uint##sz##_t)val, sysreg)
#else

I will push v3 with this change.

Cheers,
Michal

[ovmf test] 163585: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 
162359

version targeted for testing:
 ovmf 3de3c24755bdee191429c0a72aed5110e9a0b2f9
baseline version:
 ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb

Last test of basis   162359  2021-06-04 03:40:08 Z   38 days
Failing since162368  2021-06-04 15:42:59 Z   37 days  106 attempts
Testing same since   163585  2021-07-12 02:49:31 Z0 days1 attempts


People who touched revisions under test:
  Abner Chang 
  Agrawal, Sachin 
  Alexandru Elisei 
  Anthony PERARD 
  Ard Biesheuvel 
  Ashraf Ali S 
  Bret Barkelew 
  Chen, Christine 
  Corvin Köhne 
  Daniel Schaefer 
  Daoxiang Li 
  Dov Murik 
  DunTan 
  gaoliming 
  Guo Dong 
  Hao A Wu 
  Jian J Wang 
  Jianyong Wu 
  Kaaira Gupta 
  Ken Lautner 
  Kenneth Lautner 
  Kun Qin 
  Laszlo Ersek 
  Leif Lindholm 
  Liming Gao 
  Loo Tung Lun 
  Loo, Tung Lun 
  Manickavasakam Karpagavinayagam 
  Maurice Ma 
  Michael D Kinney 
  Neal Gompa 
  Ni, Ray 
  Nickle Wang 
  Patrick Rudolph 
  Pierre Gondois 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  S, Ashraf Ali 
  Sachin Agrawal 
  Sami Mujawar 
  Scottie Kuo 
  Sean Brogan 
  Sean Brogan 
  Sheng Wei 
  Sumana Venur 
  Sunil V L 
  xueshengfeng 
  Yuwei Chen 
  Zhiguang Liu 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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


Not pushing.

(No revision log; it would be 3593 lines long.)

[PATCH v3] xen/arm64: Remove READ/WRITE_SYSREG32 helper macros

[Michal Orzel]

AArch64 system registers are 64bit whereas AArch32 ones
are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
we should get rid of helpers READ/WRITE_SYSREG32
in favour of using READ/WRITE_SYSREG.

The last place in code making use of READ/WRITE_SYSREG32
on arm64 is in TVM_REG macro defining functions vreg_emulate_.
Implement a macro WRITE_SYSREG_SZ which expands as follows:
-on arm64: WRITE_SYSREG
-on arm32: WRITE_SYSREG{32/64}

As there are no other places in the code using these helpers
on arm64 - remove them.

Signed-off-by: Michal Orzel 
Reviewed-by: Bertrand Marquis 
---
Changes since v2:
-add uint##sz##_t casting
Changes since v1:
-implement WRITE_SYSREG_SZ instead of duplicating the TVM_REG
---
 xen/arch/arm/vcpreg.c   | 12 +++-
 xen/include/asm-arm/arm64/sysregs.h |  4 
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index f0cdcc8a54..e3ce56d875 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -47,6 +47,16 @@
  *
  */
 
+#ifdef CONFIG_ARM_64
+#define WRITE_SYSREG_SZ(sz, val, sysreg) WRITE_SYSREG((uint##sz##_t)val, 
sysreg)
+#else
+/*
+ * WRITE_SYSREG{32/64} on arm32 is defined as variadic macro which imposes
+ * on the below macro to be defined like that as well.
+ */
+#define WRITE_SYSREG_SZ(sz, val, sysreg...)  WRITE_SYSREG##sz(val, sysreg)
+#endif
+
 /* The name is passed from the upper macro to workaround macro expansion. */
 #define TVM_REG(sz, func, reg...)   \
 static bool func(struct cpu_user_regs *regs, uint##sz##_t *r, bool read)\
@@ -55,7 +65,7 @@ static bool func(struct cpu_user_regs *regs, uint##sz##_t *r, 
bool read)\
 bool cache_enabled = vcpu_has_cache_enabled(v); \
 \
 GUEST_BUG_ON(read); \
-WRITE_SYSREG##sz(*r, reg);  \
+WRITE_SYSREG_SZ(sz, *r, reg);   \
 \
 p2m_toggle_cache(v, cache_enabled); \
 \
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 077fd95fb7..795901e1ba 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -87,10 +87,6 @@
 
 /* Access to system registers */
 
-#define READ_SYSREG32(name) ((uint32_t)READ_SYSREG64(name))
-
-#define WRITE_SYSREG32(v, name) WRITE_SYSREG64((uint64_t)v, name)
-
 #define WRITE_SYSREG64(v, name) do {\
 uint64_t _r = v;\
 asm volatile("msr "__stringify(name)", %0" : : "r" (_r));   \
-- 
2.29.0

Re: [PATCH] tools/libxc: use uint32_t for pirq in xc_domain_irq_permission

[Julien Grall]

Hi Igor,

On 08/07/2021 03:06, Igor Druzhinin wrote:

On 07/07/2021 14:21, Julien Grall wrote:

On 07/07/2021 14:14, Jan Beulich wrote:

On 07.07.2021 14:59, Julien Grall wrote:

On 07/07/2021 13:54, Jan Beulich wrote:

On 07.07.2021 14:51, Julien Grall wrote:

On 07/07/2021 02:02, Igor Druzhinin wrote:
Current unit8_t for pirq argument in this interface is too 
restrictive
causing failures on modern hardware with lots of GSIs. That 
extends down to
XEN_DOMCTL_irq_permission ABI structure where it needs to be 
fixed up
as well. Internal Xen structures appear to be fine. Existing 
users of
the interface in tree (libxl, ocaml and python bindings) are 
already using

int for pirq representation that should be wide enough.


By "int", I am assuming you imply "signed int", is that correct?


Yes, just "int" in the meaning "signed int" - I can clarify that in the 
description.


If so, should the function xc_domain_irq_permission() interface 
take an

int in parameter and check it is not negative?


Please let's not make things worse than they are, the more that


Well, what I am trying to prevent is surprise where the caller
mistakenly pass a negative value that will be interpreted as a positive
value...


This happens all the time when converting from signed to unsigned
perhaps just internally.


I am not sure what's your point... Yes there are place in Xen that 
switch between signed and unsigned. We likely have some (latent) 
problem because of that...


Callers of libxc interface shouldn't have been using signed int at all.
They just happen to do it at least in-tree - that's what I found and 
mentioned
in the description. At the same time "int" type is for now wide enough 
so there

is no immediate rush to fix them up.

That gets a little bit tricky with bindings - they themselves expose pirq
as int. So a negative value could be passed by the caller and, given other
similar interace functions like xc_physdev_map_pirq() are using "int pirq"
to signal an error as negative value, that could be misinterpreted by lower
levels.

We can add extra checks in bindings to avoid passing all negative values to
libxc level. Would this be good enough?


Such issues are beyong annoying to debug...


No worse than any other out-of-bounds value, I would say.


  > ./CODING_STYLE is unambiguous in cases like this one.

Hmmm... The coding style mention the fixed size but nothing about the
signedness of the type...


Oh, sorry, yes. The adjustment for this even pre-dates the two
patches to ./CODING_STYLE that I've on record as pending for
nearly two years.


The alternative suggestion is to keep a unsigned type but check the bit
31 is not set.


Why? Why not bit 30 or bit 27? There's nothing special about
bit 31 in an unsigned number.


Bit 31 is the signed bit for signed number. The check would make sure 
that:
  1) The value will fit other hypercall (the PIRQ is described as int 
in a few of the structure)
  2) Catch potentially caller that would use the number that could 
potentially be interpreted as negative by other part of the hypervisor.


That said, I can live with the implicit signed -> unsigned convertion, 
however the commit message should at least be clarified because it is 
misleading.


Could you specify which statement exactly is misleading (or needs 
clariying)

in the commit message?


The commit message is mentioning that all the callers are using "signed 
int" but then the patch will use "uint32_t" without really saying why...


I think adding something along the line to:

"While all the callers are using signed int, PIRQ indexes are not meant 
to be negative. Switch the type to unsigned 32-bit and leave the caller 
clean-up for future follow-up."


Cheers,

--
Julien Grall

[qemu-mainline test] 163577: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 163321
 test-amd64-amd64-qemuu-freebsd12-amd64 13 guest-startfail REGR. vs. 163321
 test-amd64-i386-qemuu-rhel6hvm-amd 12 redhat-install fail REGR. vs. 163321
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 163321
 test-amd64-i386-freebsd10-i386 13 guest-startfail REGR. vs. 163321
 test-amd64-amd64-libvirt 14 guest-start  fail REGR. vs. 163321
 test-amd64-i386-freebsd10-amd64 13 guest-start   fail REGR. vs. 163321
 test-amd64-i386-libvirt-xsm  14 guest-start  fail REGR. vs. 163321
 test-amd64-i386-libvirt  14 guest-start  fail REGR. vs. 163321
 test-amd64-amd64-libvirt-pair 25 guest-start/debian  fail REGR. vs. 163321
 test-amd64-i386-libvirt-pair 25 guest-start/debian   fail REGR. vs. 163321
 test-amd64-amd64-qemuu-nested-amd 12 debian-hvm-install  fail REGR. vs. 163321
 test-amd64-i386-qemuu-rhel6hvm-intel 12 redhat-install   fail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install  fail REGR. vs. 163321
 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail REGR. vs. 163321
 test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
163321
 test-arm64-arm64-libvirt-xsm 14 guest-start  fail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 163321
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
163321
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 163321
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 163321
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 163321
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 163321
 test-amd64-amd64-xl-qcow212 debian-di-installfail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 
163321
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 163321
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 163321
 test-amd64-amd64-libvirt-vhd 12 debian-di-installfail REGR. vs. 163321
 test-amd64-i386-xl-qemuu-win7-amd64 12 windows-install   fail REGR. vs. 163321
 test-armhf-armhf-libvirt 14 guest-start  fail REGR. vs. 163321
 test-amd64-i386-xl-qemuu-ws16-amd64 12 windows-install   fail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-ws16-amd64 12 windows-install  fail REGR. vs. 163321
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 163321
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 163321

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-sup

Re: [RFC PATCH 2/4] xen/arm: Import ID features sanitize from linux

[Julien Grall]

On 29/06/2021 18:08, Bertrand Marquis wrote:

Import structures declared in Linux file arch/arm64/kernel/cpufeature.c
and import the required types.
Current code has been imported from Linux 5.13-rc5 (Commit ID
cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9)

Those structure will be used to sanitize the cpu features available to
the ones availble on all cores of a system even if we are on an
heterogeneous platform (from example a big/LITTLE).

For each feature field of all ID registers, those structures define what
is the safest value and if we can allow to have different values in
different cores.

This patch is introducing Linux code without any changes to it.

Signed-off-by: Bertrand Marquis 
---
  xen/arch/arm/arm64/Makefile  |   1 +
  xen/arch/arm/arm64/cpusanitize.c | 494 +++
  2 files changed, 495 insertions(+)
  create mode 100644 xen/arch/arm/arm64/cpusanitize.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 40642ff574..c626990185 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,6 +1,7 @@
  obj-y += lib/
  
  obj-y += cache.o

+obj-y += cpusanitize.o


Looking at the code, I don't think this cpusanitize.c would build after 
this patch. To allow bisection, this line would need to move when the 
file can build.



  obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) += bpi.o
  obj-$(CONFIG_EARLY_PRINTK) += debug.o
  obj-y += domctl.o
diff --git a/xen/arch/arm/arm64/cpusanitize.c b/xen/arch/arm/arm64/cpusanitize.c
new file mode 100644
index 00..4cc8378c14
--- /dev/null
+++ b/xen/arch/arm/arm64/cpusanitize.c


Any reason to not stick with the Linux name?


@@ -0,0 +1,494 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Sanitize CPU feature definitions
+ *
+ * Copyright (C) 2021 Arm Ltd.
+ * based on code from the Linux kernel, which is:
+ *  Copyright (C) 2015 ARM Ltd.


Linux has a large comment explaining the goal of the file. I think it is 
worth to keep it for Xen.



+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .


This is a redundant with the SPDX tag above. Please get rid of one of them.


+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * CPU feature register tracking
+ *
+ * The safe value of a CPUID feature field is dependent on the implications
+ * of the values assigned to it by the architecture. Based on the relationship
+ * between the values, the features are classified into 3 types - LOWER_SAFE,
+ * HIGHER_SAFE and EXACT.
+ *
+ * The lowest value of all the CPUs is chosen for LOWER_SAFE and highest
+ * for HIGHER_SAFE. It is expected that all CPUs have the same value for
+ * a field when EXACT is specified, failing which, the safe value specified
+ * in the table is chosen.
+ */
+
+enum ftr_type {
+FTR_EXACT,   /* Use a predefined safe value */
+FTR_LOWER_SAFE,  /* Smaller value is safe */
+FTR_HIGHER_SAFE, /* Bigger value is safe */
+FTR_HIGHER_OR_ZERO_SAFE, /* Bigger value is safe, but 0 is biggest */
+};
Please use the Linux coding style to stay consistent with the rest of 
the file. However, unless there is a reason to, I would prefer if the 
definition are in a separate header like Linux did.



+
+#define FTR_STRICT  true/* SANITY check strict matching required */
+#define FTR_NONSTRICT   false   /* SANITY check ignored */
+
+#define FTR_SIGNED  true/* Value should be treated as signed */
+#define FTR_UNSIGNEDfalse   /* Value should be treated as unsigned */
+
+#define FTR_VISIBLE true/* Feature visible to the user space */
+#define FTR_HIDDEN  false   /* Feature is hidden from the user */
+
+#define FTR_VISIBLE_IF_IS_ENABLED(config)   \
+(IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
+
+struct arm64_ftr_bits {
+boolsign;   /* Value is signed ? */
+boolvisible;
+boolstrict; /* CPU Sanity check: strict matching required ? */
+enum ftr_type   type;
+u8  shift;
+u8  width;
+s64 safe_val; /* safe value for FTR_EXACT features */
+};
+
+/*
+ * NOTE: The following structures are imported directly from Linux kernel and
+ * should be kept in sync.
+ * The current version has been imported from arch/arm64/kernel/cpufeature.c
+ *  from kernel version 5.13-rc5
+ */


It feels a bit odd to add this comment in the middle of the definition. 
It would be better to move it close to the copyright.



+
+#define __ARM64_FTR_BITS(SIGNED, VISIBLE

Re: [RFC PATCH V3 08/11] swiotlb: Add bounce buffer remap address setting function

[Tianyu Lan]

Hi Christoph and Robin:
 I introduced new interface set_memory_decrypted_map() to hide all
the hypervisor code behind it in the latest version. In current generic
code, only swiotlb bounce buffer needs to be decrypted and remapped in 
the same time and so keep set_memory_decrypted(). If there were more 
requests of set_memory_decrypted_map() for other platform, we may

replace set_memory_decrypted() step by step. Please have a look.
  https://lkml.org/lkml/2021/7/7/570

Thanks.

On 6/15/2021 11:24 PM, Tianyu Lan wrote:

On 6/14/2021 11:32 PM, Christoph Hellwig wrote:

On Mon, Jun 14, 2021 at 02:49:51PM +0100, Robin Murphy wrote:

FWIW, I think a better generalisation for this would be allowing
set_memory_decrypted() to return an address rather than implicitly
operating in-place, and hide all the various hypervisor hooks behind 
that.


Yes, something like that would be a good idea.  As-is
set_memory_decrypted is a pretty horribly API anyway due to passing
the address as void, and taking a size parameter while it works in units
of pages.  So I'd very much welcome a major overhaul of this API.



Hi Christoph and Robin:
 Thanks for your suggestion. I will try this idea in the next 
version. Besides make the address translation into set_memory_
decrypted() and return address, do you want to make other changes to the 
API in order to make it more reasonable(e.g size parameter)?


Thanks

[xen-unstable-smoke test] 163595: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 163474

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  93c9edbef51b31056f93a37a778326c90a83158c
baseline version:
 xen  6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf

Last test of basis   163474  2021-07-09 12:00:25 Z2 days
Failing since163480  2021-07-09 16:08:01 Z2 days   16 attempts
Testing same since   163489  2021-07-09 21:00:27 Z2 days   15 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Costin Lupu 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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
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


Not pushing.


commit 93c9edbef51b31056f93a37a778326c90a83158c
Author: Andrew Cooper 
Date:   Tue Jun 15 16:02:29 2021 +0100

tests/xenstore: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

This causes the code to be noticed by CI, which objects as follows:

  test-xenstore.c: In function 'main':
  test-xenstore.c:486:5: error: ignoring return value of 'asprintf', 
declared
  with attribute warn_unused_result [-Werror=unused-result]
   asprintf(&path, "%s/%u", TEST_PATH, getpid());
   ^

Address the CI failure by checking the asprintf() return value and exiting.

Rename xs-test to test-xenstore to be consistent with other tests.  Honour
APPEND_FLAGS too.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 6a9f5477637a9f2d1d61c0a065eeb01bf84f6484
Author: Andrew Cooper 
Date:   Tue Jun 15 15:37:49 2021 +0100

tests/cpu-policy: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Rework TARGET-y to be TARGETS, drop redundant -f's for $(RM), drop the
unconditional -O3 and use the default instead, and drop CFLAGS from the link
line but honour APPEND_LDFLAGS.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit ff759953b32286f376fda7f3ff5a17eccb542b03
Author: Andrew Cooper 
Date:   Tue Jun 15 15:22:11 2021 +0100

tests/resource: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Make all object files depend on the Makefile, drop redundant -f's for $(RM),
and use $(TARGET) when appropriate.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 79ca512a1fa68e0170a85cb71b8a8e8f4a34fb11
Author: Andrew Cooper 
Date:   Tue Jun 15 14:19:15 2021 +0100

tools/tests: Drop obsolete mce-test infrastructure

mce-test has a test suite, but it depends on xend, needs to run in-tree, and
requires manual setup of at least one guest, and manual parameters to pass
into cases.  Drop th

Re: [RFC PATCH 3/4] xen/arm: Sanitize cpuinfo ID registers fields

[Julien Grall]

Hi Bertrand,

On 29/06/2021 18:08, Bertrand Marquis wrote:

Define a sanitize_cpu function to be called on secondary cores to
sanitize the cpuinfo structure from the boot CPU.

The safest value is taken when possible and the system is marked tainted
if we encounter values which are incompatible with each other.

Call the sanitize_cpu function on all secondary cores and remove the
code disabling secondary cores if they are not the same as the boot core
as we are now able to handle this use case.

This is only supported on arm64 so cpu_sanitize is an empty static
inline on arm32.

This patch also removes the code imported from Linux that will not be
used by Xen.

Signed-off-by: Bertrand Marquis 
---
  xen/arch/arm/arm64/cpusanitize.c | 236 ---
  xen/arch/arm/smpboot.c   |   5 +-
  xen/include/asm-arm/cpufeature.h |   9 ++
  xen/include/xen/lib.h|   1 +
  4 files changed, 199 insertions(+), 52 deletions(-)

diff --git a/xen/arch/arm/arm64/cpusanitize.c b/xen/arch/arm/arm64/cpusanitize.c
index 4cc8378c14..744006ca7c 100644
--- a/xen/arch/arm/arm64/cpusanitize.c
+++ b/xen/arch/arm/arm64/cpusanitize.c
@@ -97,10 +97,6 @@ struct arm64_ftr_bits {
.width = 0, \
}
  
-static void cpu_enable_cnp(struct arm64_cpu_capabilities const *cap);

-
-static bool __system_matches_cap(unsigned int n);
-
  /*
   * NOTE: Any changes to the visibility of features should be kept in
   * sync with the documentation of the CPU feature register ABI.
@@ -277,31 +273,6 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
ARM64_FTR_END,
  };
  
-static const struct arm64_ftr_bits ftr_ctr[] = {

-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DIC_SHIFT, 
1, 1),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_IDC_SHIFT, 
1, 1),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
CTR_CWG_SHIFT, 4, 0),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
CTR_ERG_SHIFT, 4, 0),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
CTR_DMINLINE_SHIFT, 4, 1),
-   /*
-* Linux can handle differing I-cache policies. Userspace JITs will
-* make use of *minLine.
-* If we have differing I-cache policies, report it as the weakest - 
VIPT.
-*/
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_EXACT, CTR_L1IP_SHIFT, 
2, ICACHE_POLICY_VIPT),   /* L1Ip */
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
CTR_IMINLINE_SHIFT, 4, 0),
-   ARM64_FTR_END,
-};


I don't think this is should be dropped. Xen will need to know the 
safest cacheline size that can be used for cache maintenance instructions.



-
-static struct arm64_ftr_override __ro_after_init no_override = { };
-
-struct arm64_ftr_reg arm64_ftr_reg_ctrel0 = {
-   .name   = "SYS_CTR_EL0",
-   .ftr_bits   = ftr_ctr,
-   .override   = &no_override,
-};
-
  static const struct arm64_ftr_bits ftr_id_mmfr0[] = {
S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_MMFR0_INNERSHR_SHIFT, 4, 0xf),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_MMFR0_FCSE_SHIFT, 4, 0),
@@ -335,12 +306,6 @@ static const struct arm64_ftr_bits ftr_mvfr2[] = {
ARM64_FTR_END,
  };
  
-static const struct arm64_ftr_bits ftr_dczid[] = {

-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, DCZID_DZP_SHIFT, 1, 
1),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, DCZID_BS_SHIFT, 
4, 0),
-   ARM64_FTR_END,
-};


Why is this dropped?


-
  static const struct arm64_ftr_bits ftr_id_isar0[] = {
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_ISAR0_DIVIDE_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_ISAR0_DEBUG_SHIFT, 4, 0),
@@ -454,12 +419,6 @@ static const struct arm64_ftr_bits ftr_id_dfr1[] = {
ARM64_FTR_END,
  };
  
-static const struct arm64_ftr_bits ftr_zcr[] = {

-   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
-   ZCR_ELx_LEN_SHIFT, ZCR_ELx_LEN_SIZE, 0),/* LEN */
-   ARM64_FTR_END,
-};


At some point we will support SVE in Xen. So any reason we would not 
want to keep the code?



-
  /*
   * Common ftr bits for a 32bit register with all hidden, strict
   * attributes, with 4bit feature fields and a default safe value of
@@ -478,17 +437,192 @@ static const struct arm64_ftr_bits ftr_generic_32bits[] 
= {
ARM64_FTR_END,
  };
  
-/* Table for a single 32bit feature value */

-static const struct arm64_ftr_bits ftr_single32[] = {
-   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 0, 32, 0),
-   ARM64_FTR_END,
-};
-
-static const struct arm64_ftr_bits ftr_raz[] = {
-   ARM64_FTR_END,
-};
-
  /*
   * End of imported linux structures
   */
  
+static inline int __attribute

Re: [RFC PATCH 2/4] xen/arm: Import ID features sanitize from linux

[Bertrand Marquis]

Hi Julien,


> On 12 Jul 2021, at 10:36, Julien Grall  wrote:
> 
> 
> 
> On 29/06/2021 18:08, Bertrand Marquis wrote:
>> Import structures declared in Linux file arch/arm64/kernel/cpufeature.c
>> and import the required types.
>> Current code has been imported from Linux 5.13-rc5 (Commit ID
>> cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9)
>> Those structure will be used to sanitize the cpu features available to
>> the ones availble on all cores of a system even if we are on an
>> heterogeneous platform (from example a big/LITTLE).
>> For each feature field of all ID registers, those structures define what
>> is the safest value and if we can allow to have different values in
>> different cores.
>> This patch is introducing Linux code without any changes to it.
>> Signed-off-by: Bertrand Marquis 
>> ---
>>  xen/arch/arm/arm64/Makefile  |   1 +
>>  xen/arch/arm/arm64/cpusanitize.c | 494 +++
>>  2 files changed, 495 insertions(+)
>>  create mode 100644 xen/arch/arm/arm64/cpusanitize.c
>> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
>> index 40642ff574..c626990185 100644
>> --- a/xen/arch/arm/arm64/Makefile
>> +++ b/xen/arch/arm/arm64/Makefile
>> @@ -1,6 +1,7 @@
>>  obj-y += lib/
>>obj-y += cache.o
>> +obj-y += cpusanitize.o
> 
> Looking at the code, I don't think this cpusanitize.c would build after this 
> patch. To allow bisection, this line would need to move when the file can 
> build.

You are right. I will push the Makefile change to the next patch.

> 
>>  obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) += bpi.o
>>  obj-$(CONFIG_EARLY_PRINTK) += debug.o
>>  obj-y += domctl.o
>> diff --git a/xen/arch/arm/arm64/cpusanitize.c 
>> b/xen/arch/arm/arm64/cpusanitize.c
>> new file mode 100644
>> index 00..4cc8378c14
>> --- /dev/null
>> +++ b/xen/arch/arm/arm64/cpusanitize.c
> 
> Any reason to not stick with the Linux name?

File in linux is named cpufeature.c and we already have a file cpufeature.c in 
arch/arm so I wanted to prevent clashes.
As this is anyway in arm64 subdirectory the clash does not really exist so I 
will rename the file to cpufeature.c.

> 
>> @@ -0,0 +1,494 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Sanitize CPU feature definitions
>> + *
>> + * Copyright (C) 2021 Arm Ltd.
>> + * based on code from the Linux kernel, which is:
>> + *  Copyright (C) 2015 ARM Ltd.
> 
> Linux has a large comment explaining the goal of the file. I think it is 
> worth to keep it for Xen.

Ok

> 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
> 
> This is a redundant with the SPDX tag above. Please get rid of one of them.

Ok I will keep just the SPDX and copyrights.


> 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * CPU feature register tracking
>> + *
>> + * The safe value of a CPUID feature field is dependent on the implications
>> + * of the values assigned to it by the architecture. Based on the 
>> relationship
>> + * between the values, the features are classified into 3 types - 
>> LOWER_SAFE,
>> + * HIGHER_SAFE and EXACT.
>> + *
>> + * The lowest value of all the CPUs is chosen for LOWER_SAFE and highest
>> + * for HIGHER_SAFE. It is expected that all CPUs have the same value for
>> + * a field when EXACT is specified, failing which, the safe value specified
>> + * in the table is chosen.
>> + */
>> +
>> +enum ftr_type {
>> +FTR_EXACT,   /* Use a predefined safe value */
>> +FTR_LOWER_SAFE,  /* Smaller value is safe */
>> +FTR_HIGHER_SAFE, /* Bigger value is safe */
>> +FTR_HIGHER_OR_ZERO_SAFE, /* Bigger value is safe, but 0 is biggest */
>> +};
> Please use the Linux coding style to stay consistent with the rest of the 
> file. However, unless there is a reason to, I would prefer if the definition 
> are in a separate header like Linux did.

Ok, I will apply the linux coding style to the whole file.

> 
>> +
>> +#define FTR_STRICT  true/* SANITY check strict matching required */
>> +#define FTR_NONSTRICT   false   /* SANITY check ignored */
>> +
>> +#define FTR_SIGNED  true/* Value should be treated as signed */
>> +#define FTR_UNSIGNEDfalse   /* Value should be treated as unsigned */
>> +
>> +#define FTR_VISIBLE true/* Feature visible to the user space */
>> +#define FTR_HIDDEN  false   /* Feature is hidden from the user */
>> +
>> +#define FTR_VISIBLE_IF_IS_E

Re: [XEN PATCH v6 02/31] build: introduce cpp_flags macro

[Anthony PERARD]

On Wed, Jul 07, 2021 at 04:18:18PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> >  xen/Rules.mk| 7 +--
> >  xen/arch/x86/mm/Makefile| 2 +-
> >  xen/arch/x86/mm/hap/Makefile| 2 +-
> >  xen/arch/x86/mm/shadow/Makefile | 2 +-
> >  4 files changed, 8 insertions(+), 5 deletions(-)
> 
> There are two further uses, one in xen/Makefile and one in
> xen/x86/Makefile. I think both want replacing too, and the
> former suggests you also want to strip -flto alongside -Wa,%.
> I can accept the use in xen/include/Makefile not getting
> touched, as it also removes an -include option at the same
> time.

Sounds good, I'll filter -flto and convert "asm-offsets.s" and
"xen.lds".

Thanks,

-- 
Anthony PERARD

Re: [XEN PATCH v6 05/31] build: factorise generation of the linker scripts

[Anthony PERARD]

On Wed, Jul 07, 2021 at 04:25:33PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> > In Arm and X86 makefile, generating the linker script is the same, so
> > we can simply have both call the same macro.
> > 
> > We need to add *.lds files into extra-y so that Rules.mk can find the
> > .*.cmd dependency file and load it.
> > 
> > Change made to the command line:
> > - Use cpp_flags macro which simply filter -Wa,% options from $(a_flags).
> > - Added -D__LINKER__ even it is only used by Arm's lds.
> 
> I'm not really happy about this, not the least because the symbol's name
> doesn't fit its purpose (we're not linking, but producing a linker script
> at that stage), but well ...

Also, the leading "__" is probably a bad idea as I think it's reserved?

I'll look at adding creating a patch which would rename that to
LINKER_SCRIPT which seems more appropriate.

> > Signed-off-by: Anthony PERARD 
> 
> Reviewed-by: Jan Beulich 

Thanks,

-- 
Anthony PERARD

Re: [RFC PATCH 3/4] xen/arm: Sanitize cpuinfo ID registers fields

[Bertrand Marquis]

Hi Julien,

> On 12 Jul 2021, at 11:16, Julien Grall  wrote:
> 
> Hi Bertrand,
> 
> On 29/06/2021 18:08, Bertrand Marquis wrote:
>> Define a sanitize_cpu function to be called on secondary cores to
>> sanitize the cpuinfo structure from the boot CPU.
>> The safest value is taken when possible and the system is marked tainted
>> if we encounter values which are incompatible with each other.
>> Call the sanitize_cpu function on all secondary cores and remove the
>> code disabling secondary cores if they are not the same as the boot core
>> as we are now able to handle this use case.
>> This is only supported on arm64 so cpu_sanitize is an empty static
>> inline on arm32.
>> This patch also removes the code imported from Linux that will not be
>> used by Xen.
>> Signed-off-by: Bertrand Marquis 
>> ---
>>  xen/arch/arm/arm64/cpusanitize.c | 236 ---
>>  xen/arch/arm/smpboot.c   |   5 +-
>>  xen/include/asm-arm/cpufeature.h |   9 ++
>>  xen/include/xen/lib.h|   1 +
>>  4 files changed, 199 insertions(+), 52 deletions(-)
>> diff --git a/xen/arch/arm/arm64/cpusanitize.c 
>> b/xen/arch/arm/arm64/cpusanitize.c
>> index 4cc8378c14..744006ca7c 100644
>> --- a/xen/arch/arm/arm64/cpusanitize.c
>> +++ b/xen/arch/arm/arm64/cpusanitize.c
>> @@ -97,10 +97,6 @@ struct arm64_ftr_bits {
>>  .width = 0, \
>>  }
>>  -static void cpu_enable_cnp(struct arm64_cpu_capabilities const *cap);
>> -
>> -static bool __system_matches_cap(unsigned int n);
>> -
>>  /*
>>   * NOTE: Any changes to the visibility of features should be kept in
>>   * sync with the documentation of the CPU feature register ABI.
>> @@ -277,31 +273,6 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = 
>> {
>>  ARM64_FTR_END,
>>  };
>>  -static const struct arm64_ftr_bits ftr_ctr[] = {
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DIC_SHIFT, 
>> 1, 1),
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_IDC_SHIFT, 
>> 1, 1),
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
>> CTR_CWG_SHIFT, 4, 0),
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
>> CTR_ERG_SHIFT, 4, 0),
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
>> CTR_DMINLINE_SHIFT, 4, 1),
>> -/*
>> - * Linux can handle differing I-cache policies. Userspace JITs will
>> - * make use of *minLine.
>> - * If we have differing I-cache policies, report it as the weakest - 
>> VIPT.
>> - */
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_EXACT, CTR_L1IP_SHIFT, 
>> 2, ICACHE_POLICY_VIPT),   /* L1Ip */
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
>> CTR_IMINLINE_SHIFT, 4, 0),
>> -ARM64_FTR_END,
>> -};
> 
> I don't think this is should be dropped. Xen will need to know the safest 
> cacheline size that can be used for cache maintenance instructions.

I will surround those entries by #if 0 instead

> 
>> -
>> -static struct arm64_ftr_override __ro_after_init no_override = { };
>> -
>> -struct arm64_ftr_reg arm64_ftr_reg_ctrel0 = {
>> -.name   = "SYS_CTR_EL0",
>> -.ftr_bits   = ftr_ctr,
>> -.override   = &no_override,
>> -};
>> -
>>  static const struct arm64_ftr_bits ftr_id_mmfr0[] = {
>>  S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
>> ID_MMFR0_INNERSHR_SHIFT, 4, 0xf),
>>  ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
>> ID_MMFR0_FCSE_SHIFT, 4, 0),
>> @@ -335,12 +306,6 @@ static const struct arm64_ftr_bits ftr_mvfr2[] = {
>>  ARM64_FTR_END,
>>  };
>>  -static const struct arm64_ftr_bits ftr_dczid[] = {
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, DCZID_DZP_SHIFT, 1, 
>> 1),
>> -ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, DCZID_BS_SHIFT, 
>> 4, 0),
>> -ARM64_FTR_END,
>> -};
> 
> Why is this dropped?

Same I will keep that with #if 0

> 
>> -
>>  static const struct arm64_ftr_bits ftr_id_isar0[] = {
>>  ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
>> ID_ISAR0_DIVIDE_SHIFT, 4, 0),
>>  ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
>> ID_ISAR0_DEBUG_SHIFT, 4, 0),
>> @@ -454,12 +419,6 @@ static const struct arm64_ftr_bits ftr_id_dfr1[] = {
>>  ARM64_FTR_END,
>>  };
>>  -static const struct arm64_ftr_bits ftr_zcr[] = {
>> -ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
>> -ZCR_ELx_LEN_SHIFT, ZCR_ELx_LEN_SIZE, 0),/* LEN */
>> -ARM64_FTR_END,
>> -};
> 
> At some point we will support SVE in Xen. So any reason we would not want to 
> keep the code?

Same I will keep that with #if 0

> 
>> -
>>  /*
>>   * Common ftr bits for a 32bit register with all hidden, strict
>>   * attributes, with 4bit feature fields and a default safe value of
>> @@ -478,17 +437,192 @@ static const struct arm64_ftr_bits 
>> ftr_generic_32bits[] = {
>>  

Re: [XEN PATCH v6 03/31] build: use if_changed on built_in.o

[Anthony PERARD]

On Thu, Jul 08, 2021 at 01:03:46PM +0100, Andrew Cooper wrote:
> On 01/07/2021 15:09, Anthony PERARD wrote:
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index f778058f80a6..6a0cdfde2eed 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -147,17 +147,22 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
> >  c_flags += $(CFLAGS-y)
> >  a_flags += $(CFLAGS-y) $(AFLAGS-y)
> >  
> > -built_in.o: $(obj-y) $(if $(strip $(lib-y)),lib.a) $(extra-y)
> > -ifeq ($(strip $(obj-y)),)
> > -   $(CC) $(c_flags) -c -x c /dev/null -o $@
> > -else
> > +quiet_cmd_cc_builtin = LD  $@
> 
> s/LD/CC/

Will fix that.

Thanks,

-- 
Anthony PERARD

Re: [RFC PATCH 3/4] xen/arm: Sanitize cpuinfo ID registers fields

[Julien Grall]

On 12/07/2021 12:03, Bertrand Marquis wrote:

Hi Julien,


Hi Bertrand,


On 12 Jul 2021, at 11:16, Julien Grall  wrote:

Hi Bertrand,

On 29/06/2021 18:08, Bertrand Marquis wrote:

Define a sanitize_cpu function to be called on secondary cores to
sanitize the cpuinfo structure from the boot CPU.
The safest value is taken when possible and the system is marked tainted
if we encounter values which are incompatible with each other.
Call the sanitize_cpu function on all secondary cores and remove the
code disabling secondary cores if they are not the same as the boot core
as we are now able to handle this use case.
This is only supported on arm64 so cpu_sanitize is an empty static
inline on arm32.
This patch also removes the code imported from Linux that will not be
used by Xen.
Signed-off-by: Bertrand Marquis 
---
  xen/arch/arm/arm64/cpusanitize.c | 236 ---
  xen/arch/arm/smpboot.c   |   5 +-
  xen/include/asm-arm/cpufeature.h |   9 ++
  xen/include/xen/lib.h|   1 +
  4 files changed, 199 insertions(+), 52 deletions(-)
diff --git a/xen/arch/arm/arm64/cpusanitize.c b/xen/arch/arm/arm64/cpusanitize.c
index 4cc8378c14..744006ca7c 100644
--- a/xen/arch/arm/arm64/cpusanitize.c
+++ b/xen/arch/arm/arm64/cpusanitize.c
@@ -97,10 +97,6 @@ struct arm64_ftr_bits {
.width = 0, \
}
  -static void cpu_enable_cnp(struct arm64_cpu_capabilities const *cap);
-
-static bool __system_matches_cap(unsigned int n);
-
  /*
   * NOTE: Any changes to the visibility of features should be kept in
   * sync with the documentation of the CPU feature register ABI.
@@ -277,31 +273,6 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
ARM64_FTR_END,
  };
  -static const struct arm64_ftr_bits ftr_ctr[] = {
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DIC_SHIFT, 
1, 1),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_IDC_SHIFT, 
1, 1),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
CTR_CWG_SHIFT, 4, 0),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
CTR_ERG_SHIFT, 4, 0),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
CTR_DMINLINE_SHIFT, 4, 1),
-   /*
-* Linux can handle differing I-cache policies. Userspace JITs will
-* make use of *minLine.
-* If we have differing I-cache policies, report it as the weakest - 
VIPT.
-*/
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_EXACT, CTR_L1IP_SHIFT, 
2, ICACHE_POLICY_VIPT),   /* L1Ip */
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
CTR_IMINLINE_SHIFT, 4, 0),
-   ARM64_FTR_END,
-};


I don't think this is should be dropped. Xen will need to know the safest 
cacheline size that can be used for cache maintenance instructions.


I will surround those entries by #if 0 instead


But, why can't this just be sanitized as the other registers? If this is 
just a matter of missing structure in Xen, then we should add one.


The same goes for the other 2 below.

Cheers,

--
Julien Grall

[PATCH 0.5/6] xen: Implement xen/alternative-call.h for use in common code

[Andrew Cooper]

The alternative call infrastructure is x86-only for now, but the common iommu
code has a variant and more common code wants to use the infrastructure.

Introduce CONFIG_ALTERNATIVE_CALL and a conditional implemetnation so common
code can use the optimisation when available, without requiring all
architectures to implement no-op stubs.

Write some documentation, which was thus far entirely absent, covering the
requirements for an architecture to implement this optimsiation, and how to
use the infrastructure in general code.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bob Eshleman 
CC: Alistair Francis 
CC: Connor Davis 
CC: Daniel P. Smith 

This is a pre-requisite to "xsm: refactor xsm_ops handling" to avoid breaking
the ARM build.

Build test for the XSM code:

  diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
  index 5eab21e1b168..592074e8f41c 100644
  --- a/xen/xsm/xsm_core.c
  +++ b/xen/xsm/xsm_core.c
  @@ -195,6 +195,16 @@ bool __init has_xsm_magic(paddr_t start)
   }
#endif

  +#include 
  +struct foo {
  +int (*bar)(void *);
  +} foo __alt_call_maybe_initdata;
  +
  +int test_alternative_call(void)
  +{
  +return alternative_call(foo.bar, NULL);
  +}
  +
   int __init register_xsm(struct xsm_operations *ops)
{
 if ( verify(ops) )
---
 xen/arch/x86/Kconfig   |  1 +
 xen/common/Kconfig |  3 ++
 xen/include/xen/alternative-call.h | 65 ++
 3 files changed, 69 insertions(+)
 create mode 100644 xen/include/xen/alternative-call.h

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 9b164db64187..c91cdd83dc8a 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -9,6 +9,7 @@ config X86
select ARCH_SUPPORTS_INT128
select CORE_PARKING
select HAS_ALTERNATIVE
+   select ALTERNATIVE_CALL
select HAS_COMPAT
select HAS_CPUFREQ
select HAS_EHCI
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 0ddd18e11af3..1594ce4e7313 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -25,6 +25,9 @@ config GRANT_TABLE
 config HAS_ALTERNATIVE
bool
 
+config ALTERNATIVE_CALL
+   bool
+
 config HAS_COMPAT
bool
 
diff --git a/xen/include/xen/alternative-call.h 
b/xen/include/xen/alternative-call.h
new file mode 100644
index ..11d1c2606818
--- /dev/null
+++ b/xen/include/xen/alternative-call.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef XEN_ALTERNATIVE_CALL
+#define XEN_ALTERNATIVE_CALL
+
+/*
+ * Some subsystems in Xen may have multiple implementions, which can be
+ * resolved to a single implementation at boot time.  By default, this will
+ * result in the use of function pointers.
+ *
+ * Some architectures may have mechanisms for dynamically modifying .text.
+ * Using this mechnaism, function pointers can be converted to direct calls
+ * which are typically more efficient at runtime.
+ *
+ * For architectures to support:
+ *
+ * - Implement alternative_{,v}call() in asm/alternative.h.  Code generation
+ *   requirements are to emit a function pointer call at build time, and stash
+ *   enough metadata to simplify the call at boot once the implementation has
+ *   been resolved.
+ * - Select ALTERNATIVE_CALL in Kconfig.
+ *
+ * To use:
+ *
+ * Consider the following simplified example.
+ *
+ *  1) struct foo_ops __alt_call_maybe_initdata ops;
+ *
+ *  2) struct foo_ops __alt_call_maybe_initconst foo_a_ops = { ... };
+ * struct foo_ops __alt_call_maybe_initconst foo_b_ops = { ... };
+ *
+ * void foo_init(void)
+ * {
+ * ...
+ * if ( use_impl_a )
+ * ops = *foo_a_ops;
+ * else if ( use_impl_b )
+ * ops = *foo_b_ops;
+ * ...
+ * }
+ *
+ *  3) alternative_call(ops.bar, ...);
+ *
+ * There needs to a single ops object (1) which will eventually contain the
+ * function pointers.  This should be populated in foo's init() function (2)
+ * by one of the available implementations.  To call functions, use
+ * alternative_{,v}call() referencing the main ops object (3).
+ */
+
+#ifdef CONFIG_ALTERNATIVE_CALL
+
+#include 
+
+#define __alt_call_maybe_initdata  __initdata
+#define __alt_call_maybe_initconst __initconst
+
+#else
+
+#define alternative_call(func, args...)  (func)(args)
+#define alternative_vcall(func, args...) (func)(args)
+
+#define __alt_call_maybe_initdata
+#define __alt_call_maybe_initconst
+
+#endif /* !CONFIG_ALTERNATIVE_CALL */
+#endif /* XEN_ALTERNATIVE_CALL */
-- 
2.11.0

Re: [XEN PATCH v6 06/31] x86/mm: avoid building multiple .o from a single .c file

[Anthony PERARD]

On Wed, Jul 07, 2021 at 04:45:11PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> >  xen/Makefile| 11 ---
> >  xen/Rules.mk|  2 +-
> >  xen/arch/x86/mm/Makefile|  9 -
> >  xen/arch/x86/mm/guest_walk.c|  3 ---
> >  xen/arch/x86/mm/guest_walk_2.c  |  2 ++
> >  xen/arch/x86/mm/guest_walk_3.c  |  2 ++
> >  xen/arch/x86/mm/guest_walk_4.c  |  2 ++
> >  xen/arch/x86/mm/hap/Makefile|  9 -
> >  xen/arch/x86/mm/hap/guest_walk.c|  3 ---
> >  xen/arch/x86/mm/hap/guest_walk_2level.c |  2 ++
> >  xen/arch/x86/mm/hap/guest_walk_3level.c |  2 ++
> >  xen/arch/x86/mm/hap/guest_walk_4level.c |  2 ++
> 
> Is there a particular reason you've kept the "level" in these three
> file names? Preferably with them shortened (and ideally dashes used
> everywhere in the new file names instead of underscores)

I had no reason to rename them. (Also, renaming them makes the patch
bigger ;-) as we would rename the objects files.)

But I can rename as part of the patch. Should I rename all of them (mm
hap and shadow) to "guest-walk-$level.c" ? Or just "guest-$level.c" like
in shadow/ ? On the other hand, it would probably be helpful to have the same
basename for both the source and the .c that includes the source (e.g.
"guest_walk.c" and "guest_walk_2.c" have "guest_walk" in common). So if
we were to replace underscores by dashes, we should probably rename
"guest_walk.c" to "guest-walk.c" as well.

So I'll remove the "level" from the filenames in hap/ to start with in
an update to this patch, it it worth it to do more that that?

> Reviewed-by: Jan Beulich 

Thanks,

-- 
Anthony PERARD

Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing

[Will Deacon]

On Tue, Jul 06, 2021 at 12:59:57PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
> > On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > > > FWIW I was pondering the question of whether to do something along 
> > > > > those 
> > > > > lines or just scrap the default assignment entirely, so since I 
> > > > > hadn't got 
> > > > > round to saying that I've gone ahead and hacked up the alternative 
> > > > > (similarly untested) for comparison :)
> > > > >
> > > > > TBH I'm still not sure which one I prefer...
> > > > 
> > > > Claire did implement something like your suggestion originally, but
> > > > I don't really like it as it doesn't scale for adding multiple global
> > > > pools, e.g. for the 64-bit addressable one for the various encrypted
> > > > secure guest schemes.
> > > 
> > > Couple of things:
> > >  - I am not pushing to Linus the Claire's patchset until we have a
> > >resolution on this. I hope you all agree that is a sensible way
> > >forward as much as I hate doing that.
> > 
> > Sure, it's a pity but we could clearly use a bit more time to get these
> > just right and we've run out of time for 5.14.
> > 
> > I think the main question I have is how would you like to see patches for
> > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
> 
> Yes that would be perfect. If there are any dependencies on the rc1, I
> can rebase it on top of that.

Yes, please, rebasing would be very helpful. The broader rework of
'io_tlb_default_mem' is going to conflict quite badly otherwise.

Cheers,

Will

[xen-unstable-smoke test] 163602: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 163474

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  93c9edbef51b31056f93a37a778326c90a83158c
baseline version:
 xen  6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf

Last test of basis   163474  2021-07-09 12:00:25 Z3 days
Failing since163480  2021-07-09 16:08:01 Z2 days   17 attempts
Testing same since   163489  2021-07-09 21:00:27 Z2 days   16 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Costin Lupu 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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
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


Not pushing.


commit 93c9edbef51b31056f93a37a778326c90a83158c
Author: Andrew Cooper 
Date:   Tue Jun 15 16:02:29 2021 +0100

tests/xenstore: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

This causes the code to be noticed by CI, which objects as follows:

  test-xenstore.c: In function 'main':
  test-xenstore.c:486:5: error: ignoring return value of 'asprintf', 
declared
  with attribute warn_unused_result [-Werror=unused-result]
   asprintf(&path, "%s/%u", TEST_PATH, getpid());
   ^

Address the CI failure by checking the asprintf() return value and exiting.

Rename xs-test to test-xenstore to be consistent with other tests.  Honour
APPEND_FLAGS too.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 6a9f5477637a9f2d1d61c0a065eeb01bf84f6484
Author: Andrew Cooper 
Date:   Tue Jun 15 15:37:49 2021 +0100

tests/cpu-policy: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Rework TARGET-y to be TARGETS, drop redundant -f's for $(RM), drop the
unconditional -O3 and use the default instead, and drop CFLAGS from the link
line but honour APPEND_LDFLAGS.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit ff759953b32286f376fda7f3ff5a17eccb542b03
Author: Andrew Cooper 
Date:   Tue Jun 15 15:22:11 2021 +0100

tests/resource: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Make all object files depend on the Makefile, drop redundant -f's for $(RM),
and use $(TARGET) when appropriate.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 79ca512a1fa68e0170a85cb71b8a8e8f4a34fb11
Author: Andrew Cooper 
Date:   Tue Jun 15 14:19:15 2021 +0100

tools/tests: Drop obsolete mce-test infrastructure

mce-test has a test suite, but it depends on xend, needs to run in-tree, and
requires manual setup of at least one guest, and manual parameters to pass
into cases.  Drop th

Re: [XEN PATCH v6 07/31] build,include: rework compat-build-source.py

[Anthony PERARD]

On Wed, Jul 07, 2021 at 04:58:29PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> > Improvement are:
> > - give the path to xlat.lst as argument
> > - include `grep -v` in compat-build-source.py script, we don't need to
> >   write this in several scripted language.
> > 
> > Also remove dependency on Makefile as the file generation doesn't
> > depend on it anymore.
> 
> Did it before any more?

Kind of, yes, there is "grep -v" that makes the Makefile part of the
script that generates the target.

> In the subsequent patch I can see more of
> a reason to drop the dependency, but neither there nor here I'm
> really convinced: In general I think every generate file would
> better depend on the makefile containing the rule used for its
> building, as a change to that rule means the target wants
> rebuilding.

Does that mean that nearly every single targets should depends on a
"Makefile" or on "Rules.mk" ? :-)

As for the current target "compat/%.c", with this patch applied, the
only few things that the content of the file depends on is the script,
the first dependency, and "xlat.lst" (also a dependency). So the
Makefile doesn't play a role into what get's into the target, the
"mkdir" and the "mv" don't really matter. If the rule where to be
changed in a way that changed the content of the target, that would be
wrong in my opinion, the change should be done in the script.
If someone wanted to rewrite the script in a different language and thus
renaming the script, that would be fine too as make would notice that
the new script is newer that the target (as the file for the script as
just been created).

But, I guess we could start to use the "if_changed" macro here to
detected rule changes.

I really don't like when a target depends on a "Makefile" because that
means the target gets rebuilt for unrelated reason so I'd like to avoid
dependency on it when possible.

> Therefore for the moment ...
>
> > Acked-by: Jan Beulich 
> 
> ... this holds only with the dependency kept in place. But I'll
> be happy to get convinced otherwise.

Thanks,

-- 
Anthony PERARD

Re: [XEN PATCH v6 09/31] build: clean "lib.a"

[Anthony PERARD]

On Wed, Jul 07, 2021 at 05:03:12PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD 
> 
> Hmm, I was clearly under the impression (or at least assuming)
> that $(targets) would be included in what gets cleaned by the
> general rule.

Unfortunately, that not true for two reasons, the first is that `make
clean` doesn't actually remove anything from $(targets), but that could
be changed as Linux does remove files listed in $(targets). The second is
that `make clean` doesn't actually use anything from "Rules.mk" and
doesn't include it, so when running `make clean`, "lib.a" is never in
$(targets).

> Acked-by: Jan Beulich 

Thanks,

-- 
Anthony PERARD

Re: [XEN PATCH v6 11/31] build: fix clean targets when subdir-y is used

[Anthony PERARD]

On Wed, Jul 07, 2021 at 05:15:44PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> > The make variable $(subdir-y) isn't used yet but will be in a
> > following patch. Anything in $(subdir-y) doesn't to have a '/' as
> > suffix as we already now it's a directory.
> > 
> > Rework the rules so that it doesn't matter whether there is a '/' or
> > not. It also mimic more closely to the way Linux's Kbuild descend in
> > subdirectories.
> > 
> > FORCE phony target isn't needed anymore running clean, so it can be
> > removed.
> > 
> > Signed-off-by: Anthony PERARD 
> 
> Reviewed-by: Jan Beulich 

Thanks.

> > --- a/xen/scripts/Makefile.clean
> > +++ b/xen/scripts/Makefile.clean
> > @@ -12,19 +12,18 @@ include Makefile
> >  # Figure out what we need to clean from the various variables
> >  # 
> > ==
> >  subdir-all := $(subdir-y) $(subdir-n) $(subdir-) \
> > -  $(filter %/, $(obj-y) $(obj-n) $(obj-))
> > +  $(patsubst %/,%, $(filter %/, $(obj-y) $(obj-n) $(obj-)))
> 
> Isn't this a normalization which also wants doing in xen/Rules.mk for
> subdir-y? Or perhaps this is part of one of the subsequent patches
> already?

Indeed, a similar change is done as part of
build: build everything from the root dir, use obj=$subdir

Cheers,

-- 
Anthony PERARD

Re: [XEN PATCH v6 12/31] build: use subdir-y in test/Makefile

[Anthony PERARD]

On Wed, Jul 07, 2021 at 05:26:13PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> > --- a/xen/test/Makefile
> > +++ b/xen/test/Makefile
> > @@ -4,15 +4,10 @@ tests all: build
> >  
> >  ifneq ($(XEN_TARGET_ARCH),x86_32)
> >  # Xen 32-bit x86 hypervisor no longer supported, so has no test livepatches
> > -SUBDIRS += livepatch
> > +subdir-y += livepatch
> >  endif
> 
> As per xen/Rules.mk having
> 
> subdir-y := $(subdir-y) $(filter %/, $(obj-y))
> obj-y:= $(patsubst %/, %/built_in.o, $(obj-y))
> ...
> subdir-obj-y := $(filter %/built_in.o, $(obj-y))
> 
> this will result in building of livepatch/built_in.o afaict. Is
> this an intended but benign side effect?

Actually, nothing in Rules.mk is using $(subdir-y) other than updating
it with possible subdir from $(obj-y).
Recursion into a subdir only happen if it is listed in $(obj-y) and thus
should be part of a built_in.o. Rules.mk doesn't have a mean to recurs
otherwise.

So nothing is actually going to try to build livepatch/build_in.o due to
$(subdir-y).

> >  install build subtree-force-update uninstall: %:
> > -   set -e; for s in $(SUBDIRS); do \
> > +   set -e; for s in $(subdir-y); do \
> > $(MAKE) -f $(BASEDIR)/Rules.mk -C $$s $*; \
> > done
> > -
> > -clean::
> > -   set -e; for s in $(SUBDIRS); do \
> > -   $(MAKE) -f $(BASEDIR)/Rules.mk -C $$s $@; \
> > -   done
> 
> And then why can't the generic recursion rule in xen/Rules.mk
> not also be used for the "build" target? (I guess "install" and
> "uninstall" need to remain separate, and don't think I know what
> "subtree-force-update" is about.)

There's some more changed in a later patch[1] to Rules.mk which would
make it possible to remove the need for a "build" target and I actually
remove the "build" target as well as the "subtree-force-update" target.
Some more changes in tests/livepatch/ are done in patch[2] which
actually allow to remove the "build" target.

[1] build: build everything from the root dir, use obj=$subdir
[2] build: rework test/livepatch/Makefile

I think the "subtree-force-update" target as to do with having the same
logic to deal with $(SUBDIRS) as the logic in tools/ and the top
makefile, but might not have been actually hooked up.

Cheers,

-- 
Anthony PERARD

[xen-unstable test] 163594: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-amd 16 xen-boot/l1 fail REGR. vs. 163458

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-shadow   22 guest-start/debian.repeat  fail pass in 163568
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 guest-start/debianhvm.repeat fail 
pass in 163568

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 163458
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 163458
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 163458
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 163458
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 163458
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 163458
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 163458
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 163458
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 163458
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 163458
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass

version targeted for testing:
 xen  6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf
baseline version:
 xen  0f435e2b58543f5baae96e17a10ae20d3dbc28fa

Last test of basis   163458  2021-07-08 23:09:08 Z3 days
Testing same since   163478  2021-07-09 15:23:45 Z3 days6 attempts


People who touched revisions under

Re: [XEN PATCH v6 15/31] build: move make option changes check earlier

[Anthony PERARD]

On Wed, Jul 07, 2021 at 05:40:02PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> > And thus avoiding checking for those variable over and over again.
> > 
> > Signed-off-by: Anthony PERARD 
> 
> Acked-by: Jan Beulich 
> in its present shape since all you do is move existing logic. But I
> wonder if I could talk you into ...
> 
> > +ifneq ($(origin verbose),undefined)
> > +$(error "You must use 'make menuconfig' to enable/disable verbose now.")
> > +endif
> 
> ... doing away with the misleading mentioning of just "menuconfig" here.
> There are various other *config targets, many of which are also suitable
> for the purpose. Personally I've used menuconfig (in Linux) the last
> time perhaps 15 years ago, and hence I have almost forgotten about its
> existence. IOW at the very least I'd see us insert "e.g." everywhere.

Hopefully, no one ever hits those error anymore, it's been 5 years it
seems since the changes has been made.

But I can write instead:
"You must use e.g. 'make menuconfig' to enable/disable verbose now."
or maybe:
"You must use Kconfig with e.g. 'make menuconfig' to enable/disable verbose 
now."
?

Thanks,

-- 
Anthony PERARD

Re: [RFC PATCH 3/4] xen/arm: Sanitize cpuinfo ID registers fields

[Bertrand Marquis]

Hi Julien,

> On 12 Jul 2021, at 12:13, Julien Grall  wrote:
> 
> 
> 
> On 12/07/2021 12:03, Bertrand Marquis wrote:
>> Hi Julien,
> 
> Hi Bertrand,
> 
>>> On 12 Jul 2021, at 11:16, Julien Grall  wrote:
>>> 
>>> Hi Bertrand,
>>> 
>>> On 29/06/2021 18:08, Bertrand Marquis wrote:
 Define a sanitize_cpu function to be called on secondary cores to
 sanitize the cpuinfo structure from the boot CPU.
 The safest value is taken when possible and the system is marked tainted
 if we encounter values which are incompatible with each other.
 Call the sanitize_cpu function on all secondary cores and remove the
 code disabling secondary cores if they are not the same as the boot core
 as we are now able to handle this use case.
 This is only supported on arm64 so cpu_sanitize is an empty static
 inline on arm32.
 This patch also removes the code imported from Linux that will not be
 used by Xen.
 Signed-off-by: Bertrand Marquis 
 ---
  xen/arch/arm/arm64/cpusanitize.c | 236 ---
  xen/arch/arm/smpboot.c   |   5 +-
  xen/include/asm-arm/cpufeature.h |   9 ++
  xen/include/xen/lib.h|   1 +
  4 files changed, 199 insertions(+), 52 deletions(-)
 diff --git a/xen/arch/arm/arm64/cpusanitize.c 
 b/xen/arch/arm/arm64/cpusanitize.c
 index 4cc8378c14..744006ca7c 100644
 --- a/xen/arch/arm/arm64/cpusanitize.c
 +++ b/xen/arch/arm/arm64/cpusanitize.c
 @@ -97,10 +97,6 @@ struct arm64_ftr_bits {
.width = 0, \
}
  -static void cpu_enable_cnp(struct arm64_cpu_capabilities const *cap);
 -
 -static bool __system_matches_cap(unsigned int n);
 -
  /*
   * NOTE: Any changes to the visibility of features should be kept in
   * sync with the documentation of the CPU feature register ABI.
 @@ -277,31 +273,6 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] 
 = {
ARM64_FTR_END,
  };
  -static const struct arm64_ftr_bits ftr_ctr[] = {
 -  ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
 -  ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DIC_SHIFT, 
 1, 1),
 -  ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_IDC_SHIFT, 
 1, 1),
 -  ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
 CTR_CWG_SHIFT, 4, 0),
 -  ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
 CTR_ERG_SHIFT, 4, 0),
 -  ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
 CTR_DMINLINE_SHIFT, 4, 1),
 -  /*
 -   * Linux can handle differing I-cache policies. Userspace JITs will
 -   * make use of *minLine.
 -   * If we have differing I-cache policies, report it as the weakest - 
 VIPT.
 -   */
 -  ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_EXACT, CTR_L1IP_SHIFT, 
 2, ICACHE_POLICY_VIPT),   /* L1Ip */
 -  ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
 CTR_IMINLINE_SHIFT, 4, 0),
 -  ARM64_FTR_END,
 -};
>>> 
>>> I don't think this is should be dropped. Xen will need to know the safest 
>>> cacheline size that can be used for cache maintenance instructions.
>> I will surround those entries by #if 0 instead
> 
> But, why can't this just be sanitized as the other registers? If this is just 
> a matter of missing structure in Xen, then we should add one.
> 
> The same goes for the other 2 below.

The point of the RFC was to validate the way to go and do the base.

Those require changes out of the cpuinfo and are on my todo list to.

Regards
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [XEN PATCH v6 17/31] build: convert binfile use to if_changed

[Anthony PERARD]

On Wed, Jul 07, 2021 at 05:48:57PM +0200, Jan Beulich wrote:
> On 01.07.2021 16:09, Anthony PERARD wrote:
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -80,8 +80,12 @@ config.gz: $(CONF_FILE)
> >  
> >  config_data.o: config.gz
> >  
> > -config_data.S: $(BASEDIR)/tools/binfile
> > -   $(SHELL) $(BASEDIR)/tools/binfile $@ config.gz xen_config_data
> > +quiet_cmd_binfile = BINFILE $@
> > +cmd_binfile = $(SHELL) $< $@ config.gz xen_config_data
> 
> This is an abuse of $< which I consider overly confusing:
> $(BASEDIR)/tools/binfile is not the input file to the rule. Instead
> the script generates an assembly file "out of thin air", with not
> input files at all. The rule and ...
> 
> > +config_data.S: $(BASEDIR)/tools/binfile FORCE
> 
> ... dependency shouldn't give a different impression. What would
> be nice (without having checked how difficult this might be) would
> be if quiet_cmd_binfile and cmd_binfile could move to xen/Rules.mk
> and merely be used from here (and the other location, where the
> same concern obviously applies).

I've though of having cmd_binfile in Rules.mk, but it's made more
complicated by having a "-i" flag used in flask/.

So one things I've writen was:

config_data.S: $(BASEDIR)/tools/binfile FORCE
   $(call if_changed,binfile,,config.gz xen_config_data)
flask-policy.S: $(BASEDIR)/tools/binfile FORCE
   $(call if_changed,binfile,-i,policy.bin xsm_flask_init_policy)

with:
cmd_binfile = $(SHELL) $(BASEDIR)/tools/binfile $(2) $@ $(3)

I thought this would be confusing, so I avoid it.
But maybe with the lists of flags at the end, it would be better:
   $(call if_changed,binfile,policy.bin xsm_flask_init_policy,-i)

Still want to move cmd_binfile to Rules.mk?

But I can at least spell "tools/binfile" instead of using $<.

Thanks,

-- 
Anthony PERARD

[ovmf test] 163598: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 
162359

version targeted for testing:
 ovmf 40a9066439cbab235933525810f46f03806c6ef1
baseline version:
 ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb

Last test of basis   162359  2021-06-04 03:40:08 Z   38 days
Failing since162368  2021-06-04 15:42:59 Z   38 days  107 attempts
Testing same since   163598  2021-07-12 09:12:40 Z0 days1 attempts


People who touched revisions under test:
  Abner Chang 
  Agrawal, Sachin 
  Alexandru Elisei 
  Anthony PERARD 
  Ard Biesheuvel 
  Ashraf Ali S 
  Bob Feng 
  Bret Barkelew 
  Chen, Christine 
  Corvin Köhne 
  Daniel Schaefer 
  Daoxiang Li 
  Dov Murik 
  DunTan 
  gaoliming 
  Guo Dong 
  Hao A Wu 
  Jian J Wang 
  Jianyong Wu 
  Kaaira Gupta 
  Ken Lautner 
  Kenneth Lautner 
  Kun Qin 
  Laszlo Ersek 
  Leif Lindholm 
  Liming Gao 
  Loo Tung Lun 
  Loo, Tung Lun 
  Manickavasakam Karpagavinayagam 
  Maurice Ma 
  Michael D Kinney 
  Neal Gompa 
  Ni, Ray 
  Nickle Wang 
  Patrick Rudolph 
  Pierre Gondois 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  S, Ashraf Ali 
  Sachin Agrawal 
  Sami Mujawar 
  Scottie Kuo 
  Sean Brogan 
  Sean Brogan 
  Sheng Wei 
  Sumana Venur 
  Sunil V L 
  xueshengfeng 
  Yuwei Chen 
  Zhiguang Liu 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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


Not pushing.

(No revision log; it would be 3617 lines long.)

Re: gitlab merge request -> list patchbomb workflows

[Stefano Stabellini]

On Fri, 9 Jul 2021, Ian Jackson wrote:
> Julien Grall writes ("Re: gitlab merge request -> list patchbomb workflows"):
> > I have recently started to use b4 [1] to fetch patches and collect tags 
> > from the mailing list. I am wondering if the tools could be extended to 
> > also allow a quick look through of the review "state" of each patch?
> 
> Cool.  That's interesting.  I need to think about it some more, but I
> think this is a possible alternative to using patchwork for the
> analysis task.
> 
> Also, if a robot wanted to post a v2 it could use b4 to fold the acks
> etc. into the repost, without the submitter having to add them to the
> git branch.

Hi Ian,

I think kernel.org is already working on the same feature, you might
want to ask Konstantin Ryabitsev about it.

Cheers,

Stefano

Re: [PATCH 1/2] IOMMU: correct parsing of "quarantine=scratch-page"

[Paul Durrant]

On 07/07/2021 14:21, Jan Beulich wrote:

During the multiple renames of the sub-option I apparently forgot to
update the left side of the &&, and this pretty consistently.

Fixes: 980d6acf1517 ("IOMMU: make DMA containment of quarantined devices 
optional")

Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 


Reviewed-by: Paul Durrant 



--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -82,7 +82,7 @@ static int __init parse_iommu_param(cons
  #ifdef CONFIG_HAS_PCI
  else if ( (val = parse_boolean("quarantine", s, ss)) >= 0 )
  iommu_quarantine = val;
-else if ( ss == s + 15 && !strncmp(s, "quarantine=scratch-page", 23) )
+else if ( ss == s + 23 && !strncmp(s, "quarantine=scratch-page", 23) )
  iommu_quarantine = IOMMU_quarantine_scratch_page;
  #endif
  #ifdef CONFIG_X86

Re: [PATCH 2/2] CHANGELOG: record changed PCI device quarantining default

[Paul Durrant]

On 07/07/2021 14:22, Jan Beulich wrote:

This amends commit 980d6acf1517 ("IOMMU: make DMA containment of
quarantined devices optional").

Signed-off-by: Jan Beulich 


Reviewed-by: Paul Durrant 



--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -10,6 +10,13 @@ The format is based on [Keep a Changelog
   - XENSTORED_ROOTDIR environment variable from configuartion files and
 initscripts, due to being unused.
  
+### Changed

+ - Quarantining of passed-through PCI devices no longer defaults to directing 
I/O to a scratch
+   page, matching original post-XSA-302 behavior (albeit the change was also 
backported, first
+   appearing in 4.12.2 and 4.11.4). Prior (4.13...4.15-like) behavior can be 
arranged for
+   either by enabling the IOMMU_QUARANTINE_SCRATCH_PAGE setting at build 
(configuration) time
+   or by passing "iommu=quarantine=scratch-page" on the hypervisor command 
line.
+
  ## [4.15.0 
UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0)
 - TBD
  
  ### Added / support upgraded

[xen-unstable-smoke test] 163607: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 163474

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  93c9edbef51b31056f93a37a778326c90a83158c
baseline version:
 xen  6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf

Last test of basis   163474  2021-07-09 12:00:25 Z3 days
Failing since163480  2021-07-09 16:08:01 Z3 days   18 attempts
Testing same since   163489  2021-07-09 21:00:27 Z2 days   17 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Costin Lupu 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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
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


Not pushing.


commit 93c9edbef51b31056f93a37a778326c90a83158c
Author: Andrew Cooper 
Date:   Tue Jun 15 16:02:29 2021 +0100

tests/xenstore: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

This causes the code to be noticed by CI, which objects as follows:

  test-xenstore.c: In function 'main':
  test-xenstore.c:486:5: error: ignoring return value of 'asprintf', 
declared
  with attribute warn_unused_result [-Werror=unused-result]
   asprintf(&path, "%s/%u", TEST_PATH, getpid());
   ^

Address the CI failure by checking the asprintf() return value and exiting.

Rename xs-test to test-xenstore to be consistent with other tests.  Honour
APPEND_FLAGS too.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 6a9f5477637a9f2d1d61c0a065eeb01bf84f6484
Author: Andrew Cooper 
Date:   Tue Jun 15 15:37:49 2021 +0100

tests/cpu-policy: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Rework TARGET-y to be TARGETS, drop redundant -f's for $(RM), drop the
unconditional -O3 and use the default instead, and drop CFLAGS from the link
line but honour APPEND_LDFLAGS.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit ff759953b32286f376fda7f3ff5a17eccb542b03
Author: Andrew Cooper 
Date:   Tue Jun 15 15:22:11 2021 +0100

tests/resource: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Make all object files depend on the Makefile, drop redundant -f's for $(RM),
and use $(TARGET) when appropriate.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 79ca512a1fa68e0170a85cb71b8a8e8f4a34fb11
Author: Andrew Cooper 
Date:   Tue Jun 15 14:19:15 2021 +0100

tools/tests: Drop obsolete mce-test infrastructure

mce-test has a test suite, but it depends on xend, needs to run in-tree, and
requires manual setup of at least one guest, and manual parameters to pass
into cases.  Drop th

Re: [RFC PATCH 3/4] xen/arm: Sanitize cpuinfo ID registers fields

[Julien Grall]

Hi Bertrand,

On 12/07/2021 17:29, Bertrand Marquis wrote:

On 12 Jul 2021, at 12:13, Julien Grall  wrote:



On 12/07/2021 12:03, Bertrand Marquis wrote:

Hi Julien,


Hi Bertrand,


On 12 Jul 2021, at 11:16, Julien Grall  wrote:

Hi Bertrand,

On 29/06/2021 18:08, Bertrand Marquis wrote:

Define a sanitize_cpu function to be called on secondary cores to
sanitize the cpuinfo structure from the boot CPU.
The safest value is taken when possible and the system is marked tainted
if we encounter values which are incompatible with each other.
Call the sanitize_cpu function on all secondary cores and remove the
code disabling secondary cores if they are not the same as the boot core
as we are now able to handle this use case.
This is only supported on arm64 so cpu_sanitize is an empty static
inline on arm32.
This patch also removes the code imported from Linux that will not be
used by Xen.
Signed-off-by: Bertrand Marquis 
---
  xen/arch/arm/arm64/cpusanitize.c | 236 ---
  xen/arch/arm/smpboot.c   |   5 +-
  xen/include/asm-arm/cpufeature.h |   9 ++
  xen/include/xen/lib.h|   1 +
  4 files changed, 199 insertions(+), 52 deletions(-)
diff --git a/xen/arch/arm/arm64/cpusanitize.c b/xen/arch/arm/arm64/cpusanitize.c
index 4cc8378c14..744006ca7c 100644
--- a/xen/arch/arm/arm64/cpusanitize.c
+++ b/xen/arch/arm/arm64/cpusanitize.c
@@ -97,10 +97,6 @@ struct arm64_ftr_bits {
.width = 0, \
}
  -static void cpu_enable_cnp(struct arm64_cpu_capabilities const *cap);
-
-static bool __system_matches_cap(unsigned int n);
-
  /*
   * NOTE: Any changes to the visibility of features should be kept in
   * sync with the documentation of the CPU feature register ABI.
@@ -277,31 +273,6 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
ARM64_FTR_END,
  };
  -static const struct arm64_ftr_bits ftr_ctr[] = {
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DIC_SHIFT, 
1, 1),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_IDC_SHIFT, 
1, 1),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
CTR_CWG_SHIFT, 4, 0),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, 
CTR_ERG_SHIFT, 4, 0),
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
CTR_DMINLINE_SHIFT, 4, 1),
-   /*
-* Linux can handle differing I-cache policies. Userspace JITs will
-* make use of *minLine.
-* If we have differing I-cache policies, report it as the weakest - 
VIPT.
-*/
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_EXACT, CTR_L1IP_SHIFT, 
2, ICACHE_POLICY_VIPT),   /* L1Ip */
-   ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
CTR_IMINLINE_SHIFT, 4, 0),
-   ARM64_FTR_END,
-};


I don't think this is should be dropped. Xen will need to know the safest 
cacheline size that can be used for cache maintenance instructions.

I will surround those entries by #if 0 instead


But, why can't this just be sanitized as the other registers? If this is just a 
matter of missing structure in Xen, then we should add one.

The same goes for the other 2 below.


The point of the RFC was to validate the way to go and do the base.


Right... I was commenting on your suggestion to switch to #if 0 for the 
next version. I assume this will be a non-RFC and...



Those require changes out of the cpuinfo and are on my todo list to
... it wasn't clear to me that the change on the cpuinfo was on your 
TODO list for the next version.


So I prefer to ask before you spend time working on a change that I may 
disagree with ;).


Cheers,

--
Julien Grall

Re: [RFC PATCH 2/4] xen/arm: Import ID features sanitize from linux

[Julien Grall]

Hi Bertrand,

On 12/07/2021 11:50, Bertrand Marquis wrote:

+#define __ARM64_FTR_BITS(SIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, 
SAFE_VAL) \
+   {   \
+   .sign = SIGNED, \
+   .visible = VISIBLE, \
+   .strict = STRICT,   \
+   .type = TYPE,   \
+   .shift = SHIFT, \
+   .width = WIDTH, \
+   .safe_val = SAFE_VAL,   \
+   }
+
+/* Define a feature with unsigned values */
+#define ARM64_FTR_BITS(VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
+   __ARM64_FTR_BITS(FTR_UNSIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, 
SAFE_VAL)
+
+/* Define a feature with a signed value */
+#define S_ARM64_FTR_BITS(VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
+   __ARM64_FTR_BITS(FTR_SIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, 
SAFE_VAL)
+
+#define ARM64_FTR_END  \
+   {   \
+   .width = 0, \
+   }
+
+static void cpu_enable_cnp(struct arm64_cpu_capabilities const *cap);


This function is not defined in the code you import.


I imported the block I am interested in from Linux and I am filtering it in the
Next patch where I remove those function prototypes.
I find it a bit confusing because most of the code imported makes sense 
except the two prototypes. At the same time...




This was to allow easier update of the code.


... I agree with this because if we need a resync of this patch, we may 
inadvertently re-introduce the prototype. So...




Should I filter directly when importing linux code then ?


... I will leave that up to you.

Cheers,

--
Julien Grall

[PATCH v2 00/10] xsm: refactoring xsm hooks

[Daniel P. Smith]

Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
patch set is being split into two separate patch sets. This is the first
patch set and is focused purely on the clean up and refactoring of the
XSM hooks.

This patch set refactors the xsm_ops wrapper hooks to use the alternative_call
infrastructure. Then proceeds to move and realign the headers to remove the
psuedo is/is not enable implementation. The remainder of the changes are clean 
up
and removing no longer necessary abstractions.

v2:
 - restructured the patches, breaking them up as needed
 - incorporate Andrew Cooper's alternative call common code
 - change XSM module registration, removing register_xsm
 - incoporate KConfig recommendations
 - reworded commit messages
 - incorporate macro expansion recommendations
 - misc clean-up fallout from recommendations

Andrew Cooper (1):
  xen: Implement xen/alternative-call.h for use in common code

Daniel P. Smith (9):
  xsm: refactor xsm_ops handling
  xsm: remove the ability to disable flask
  xsm: convert xsm_ops hook calls to alternative call
  xsm: decouple xsm header inclusion selection
  xsm: enable xsm to always be included
  xsm: drop generic event channel labeling
  xsm: remove xsm_default_t from hook definitions
  xsm: expand the function related macros in dummy.h
  xsm: removing the XSM_ASSERT_ACTION macro

 xen/arch/arm/dm.c |   2 +-
 xen/arch/arm/domctl.c |   6 +-
 xen/arch/arm/hvm.c|   2 +-
 xen/arch/arm/mm.c |   2 +-
 xen/arch/arm/platform_hypercall.c |   2 +-
 xen/arch/x86/Kconfig  |   1 +
 xen/arch/x86/cpu/mcheck/mce.c |   2 +-
 xen/arch/x86/cpu/vpmu.c   |   2 +-
 xen/arch/x86/domctl.c |   8 +-
 xen/arch/x86/hvm/dm.c |   2 +-
 xen/arch/x86/hvm/hvm.c|  12 +-
 xen/arch/x86/irq.c|   5 +-
 xen/arch/x86/mm.c |  20 +-
 xen/arch/x86/mm/mem_paging.c  |   2 +-
 xen/arch/x86/mm/mem_sharing.c |   9 +-
 xen/arch/x86/mm/p2m.c |   2 +-
 xen/arch/x86/mm/paging.c  |   4 +-
 xen/arch/x86/mm/shadow/set.c  |   2 +-
 xen/arch/x86/msi.c|   3 +-
 xen/arch/x86/pci.c|   2 +-
 xen/arch/x86/physdev.c|  17 +-
 xen/arch/x86/platform_hypercall.c |  10 +-
 xen/arch/x86/pv/emul-priv-op.c|   2 +-
 xen/arch/x86/sysctl.c |   4 +-
 xen/common/Kconfig|  48 +-
 xen/common/domain.c   |   4 +-
 xen/common/domctl.c   |  12 +-
 xen/common/event_channel.c|  12 +-
 xen/common/grant_table.c  |  16 +-
 xen/common/hypfs.c|   2 +-
 xen/common/kernel.c   |   2 +-
 xen/common/kexec.c|   2 +-
 xen/common/mem_access.c   |   2 +-
 xen/common/memory.c   |  16 +-
 xen/common/monitor.c  |   2 +-
 xen/common/sched/core.c   |   6 +-
 xen/common/sysctl.c   |   8 +-
 xen/common/vm_event.c |   2 +-
 xen/common/xenoprof.c |   2 +-
 xen/drivers/char/console.c|   2 +-
 xen/drivers/passthrough/device_tree.c |   4 +-
 xen/drivers/passthrough/pci.c |  12 +-
 xen/include/xen/alternative-call.h|  65 +++
 xen/include/xen/sched.h   |   9 -
 xen/include/xsm/dummy.h   | 774 --
 xen/include/xsm/xsm-core.h| 237 
 xen/include/xsm/xsm.h | 623 +++--
 xen/xsm/Makefile  |   4 +-
 xen/xsm/dummy.c   |   7 +-
 xen/xsm/dummy.h   | 696 +++
 xen/xsm/flask/flask_op.c  |  30 -
 xen/xsm/flask/hooks.c |  11 +-
 xen/xsm/silo.c|  23 +-
 xen/xsm/xsm_core.c|  76 +--
 54 files changed, 1381 insertions(+), 1451 deletions(-)
 create mode 100644 xen/include/xen/alternative-call.h
 delete mode 100644 xen/include/xsm/dummy.h
 create mode 100644 xen/include/xsm/xsm-core.h
 create mode 100644 xen/xsm/dummy.h

-- 
2.20.1

[PATCH v2 01/10] xen: Implement xen/alternative-call.h for use in common code

[Daniel P. Smith]

From: Andrew Cooper 

The alternative call infrastructure is x86-only for now, but the common iommu
code has a variant and more common code wants to use the infrastructure.

Introduce CONFIG_ALTERNATIVE_CALL and a conditional implemetnation so common
code can use the optimisation when available, without requiring all
architectures to implement no-op stubs.

Write some documentation, which was thus far entirely absent, covering the
requirements for an architecture to implement this optimsiation, and how to
use the infrastructure in general code.

Signed-off-by: Andrew Cooper 
---
 xen/arch/x86/Kconfig   |  1 +
 xen/common/Kconfig |  3 ++
 xen/include/xen/alternative-call.h | 65 ++
 3 files changed, 69 insertions(+)
 create mode 100644 xen/include/xen/alternative-call.h

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 9b164db641..c91cdd83dc 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -9,6 +9,7 @@ config X86
select ARCH_SUPPORTS_INT128
select CORE_PARKING
select HAS_ALTERNATIVE
+   select ALTERNATIVE_CALL
select HAS_COMPAT
select HAS_CPUFREQ
select HAS_EHCI
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 0ddd18e11a..1594ce4e73 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -25,6 +25,9 @@ config GRANT_TABLE
 config HAS_ALTERNATIVE
bool
 
+config ALTERNATIVE_CALL
+   bool
+
 config HAS_COMPAT
bool
 
diff --git a/xen/include/xen/alternative-call.h 
b/xen/include/xen/alternative-call.h
new file mode 100644
index 00..11d1c26068
--- /dev/null
+++ b/xen/include/xen/alternative-call.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef XEN_ALTERNATIVE_CALL
+#define XEN_ALTERNATIVE_CALL
+
+/*
+ * Some subsystems in Xen may have multiple implementions, which can be
+ * resolved to a single implementation at boot time.  By default, this will
+ * result in the use of function pointers.
+ *
+ * Some architectures may have mechanisms for dynamically modifying .text.
+ * Using this mechnaism, function pointers can be converted to direct calls
+ * which are typically more efficient at runtime.
+ *
+ * For architectures to support:
+ *
+ * - Implement alternative_{,v}call() in asm/alternative.h.  Code generation
+ *   requirements are to emit a function pointer call at build time, and stash
+ *   enough metadata to simplify the call at boot once the implementation has
+ *   been resolved.
+ * - Select ALTERNATIVE_CALL in Kconfig.
+ *
+ * To use:
+ *
+ * Consider the following simplified example.
+ *
+ *  1) struct foo_ops __alt_call_maybe_initdata ops;
+ *
+ *  2) struct foo_ops __alt_call_maybe_initconst foo_a_ops = { ... };
+ * struct foo_ops __alt_call_maybe_initconst foo_b_ops = { ... };
+ *
+ * void foo_init(void)
+ * {
+ * ...
+ * if ( use_impl_a )
+ * ops = *foo_a_ops;
+ * else if ( use_impl_b )
+ * ops = *foo_b_ops;
+ * ...
+ * }
+ *
+ *  3) alternative_call(ops.bar, ...);
+ *
+ * There needs to a single ops object (1) which will eventually contain the
+ * function pointers.  This should be populated in foo's init() function (2)
+ * by one of the available implementations.  To call functions, use
+ * alternative_{,v}call() referencing the main ops object (3).
+ */
+
+#ifdef CONFIG_ALTERNATIVE_CALL
+
+#include 
+
+#define __alt_call_maybe_initdata  __initdata
+#define __alt_call_maybe_initconst __initconst
+
+#else
+
+#define alternative_call(func, args...)  (func)(args)
+#define alternative_vcall(func, args...) (func)(args)
+
+#define __alt_call_maybe_initdata
+#define __alt_call_maybe_initconst
+
+#endif /* !CONFIG_ALTERNATIVE_CALL */
+#endif /* XEN_ALTERNATIVE_CALL */
-- 
2.20.1

[PATCH v2 02/10] xsm: refactor xsm_ops handling

[Daniel P. Smith]

This converts the global xsm_ops from being a pointer to a struct xsm_ops to 
being an
explicit instance. It then reworks the XSM modules init function to
return their xsm_ops struct which is copied in to the global xsm_ops.

Signed-off-by: Daniel P. Smith 
---
 xen/include/xsm/xsm.h| 215 ---
 xen/xsm/dummy.c  |   2 -
 xen/xsm/flask/flask_op.c |   4 +-
 xen/xsm/flask/hooks.c|  11 +-
 xen/xsm/silo.c   |   5 +-
 xen/xsm/xsm_core.c   |  72 +++--
 6 files changed, 158 insertions(+), 151 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ad3cddbf7d..a8805f514b 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -191,295 +191,295 @@ struct xsm_operations {
 
 #ifdef CONFIG_XSM
 
-extern struct xsm_operations *xsm_ops;
+extern struct xsm_operations xsm_ops;
 
 #ifndef XSM_NO_WRAPPERS
 
 static inline void xsm_security_domaininfo (struct domain *d,
 struct xen_domctl_getdomaininfo *info)
 {
-xsm_ops->security_domaininfo(d, info);
+xsm_ops.security_domaininfo(d, info);
 }
 
 static inline int xsm_domain_create (xsm_default_t def, struct domain *d, u32 
ssidref)
 {
-return xsm_ops->domain_create(d, ssidref);
+return xsm_ops.domain_create(d, ssidref);
 }
 
 static inline int xsm_getdomaininfo (xsm_default_t def, struct domain *d)
 {
-return xsm_ops->getdomaininfo(d);
+return xsm_ops.getdomaininfo(d);
 }
 
 static inline int xsm_domctl_scheduler_op (xsm_default_t def, struct domain 
*d, int cmd)
 {
-return xsm_ops->domctl_scheduler_op(d, cmd);
+return xsm_ops.domctl_scheduler_op(d, cmd);
 }
 
 static inline int xsm_sysctl_scheduler_op (xsm_default_t def, int cmd)
 {
-return xsm_ops->sysctl_scheduler_op(cmd);
+return xsm_ops.sysctl_scheduler_op(cmd);
 }
 
 static inline int xsm_set_target (xsm_default_t def, struct domain *d, struct 
domain *e)
 {
-return xsm_ops->set_target(d, e);
+return xsm_ops.set_target(d, e);
 }
 
 static inline int xsm_domctl (xsm_default_t def, struct domain *d, int cmd)
 {
-return xsm_ops->domctl(d, cmd);
+return xsm_ops.domctl(d, cmd);
 }
 
 static inline int xsm_sysctl (xsm_default_t def, int cmd)
 {
-return xsm_ops->sysctl(cmd);
+return xsm_ops.sysctl(cmd);
 }
 
 static inline int xsm_readconsole (xsm_default_t def, uint32_t clear)
 {
-return xsm_ops->readconsole(clear);
+return xsm_ops.readconsole(clear);
 }
 
 static inline int xsm_evtchn_unbound (xsm_default_t def, struct domain *d1, 
struct evtchn *chn,
 domid_t 
id2)
 {
-return xsm_ops->evtchn_unbound(d1, chn, id2);
+return xsm_ops.evtchn_unbound(d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain (xsm_default_t def, struct domain *d1,
 struct evtchn *chan1, struct domain *d2, struct evtchn *chan2)
 {
-return xsm_ops->evtchn_interdomain(d1, chan1, d2, chan2);
+return xsm_ops.evtchn_interdomain(d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-xsm_ops->evtchn_close_post(chn);
+xsm_ops.evtchn_close_post(chn);
 }
 
 static inline int xsm_evtchn_send (xsm_default_t def, struct domain *d, struct 
evtchn *chn)
 {
-return xsm_ops->evtchn_send(d, chn);
+return xsm_ops.evtchn_send(d, chn);
 }
 
 static inline int xsm_evtchn_status (xsm_default_t def, struct domain *d, 
struct evtchn *chn)
 {
-return xsm_ops->evtchn_status(d, chn);
+return xsm_ops.evtchn_status(d, chn);
 }
 
 static inline int xsm_evtchn_reset (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops->evtchn_reset(d1, d2);
+return xsm_ops.evtchn_reset(d1, d2);
 }
 
 static inline int xsm_grant_mapref (xsm_default_t def, struct domain *d1, 
struct domain *d2,
 uint32_t flags)
 {
-return xsm_ops->grant_mapref(d1, d2, flags);
+return xsm_ops.grant_mapref(d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops->grant_unmapref(d1, d2);
+return xsm_ops.grant_unmapref(d1, d2);
 }
 
 static inline int xsm_grant_setup (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops->grant_setup(d1, d2);
+return xsm_ops.grant_setup(d1, d2);
 }
 
 static inline int xsm_grant_transfer (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops->grant_transfer(d1, d2);
+return xsm_ops.grant_transfer(d1, d2);
 }
 
 static inline int xsm_grant_copy (xsm_default_t def, struct domain *d1, struct 
domain *d2)
 {
-return xsm_ops->grant_copy(d1, d2);
+return xsm_ops.grant_copy(d1, d2);
 }
 
 static inline int xsm_grant_query_size (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops->grant_query_size(d1, d2);
+return xsm_ops.grant

[PATCH v2 03/10] xsm: remove the ability to disable flask

[Daniel P. Smith]

The flask XSM module provided the ability to switch from flask back to
the dummy XSM module during runtime. With this removal the only way to
switch between XSM modules is at boot time.

Signed-off-by: Daniel P. Smith 
---
 xen/xsm/flask/flask_op.c | 32 
 1 file changed, 32 deletions(-)

diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 32e079d676..f41c025391 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -223,34 +223,6 @@ static int flask_security_sid(struct xen_flask_sid_context 
*arg)
 
 #ifndef COMPAT
 
-static int flask_disable(void)
-{
-static int flask_disabled = 0;
-struct xsm_operations default_ops;
-
-if ( ss_initialized )
-{
-/* Not permitted after initial policy load. */
-return -EINVAL;
-}
-
-if ( flask_disabled )
-{
-/* Only do this once. */
-return -EINVAL;
-}
-
-printk("Flask:  Disabled at runtime.\n");
-
-flask_disabled = 1;
-
-/* Reset xsm_ops to the original module. */
-xsm_fixup_ops(&default_ops);
-xsm_ops = default_ops;
-
-return 0;
-}
-
 static int flask_security_setavc_threshold(struct xen_flask_setavc_threshold 
*arg)
 {
 int rv = 0;
@@ -700,10 +672,6 @@ ret_t do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) 
u_flask_op)
 rv = flask_mls_enabled;
 break;
 
-case FLASK_DISABLE:
-rv = flask_disable();
-break;
-
 case FLASK_GETAVC_THRESHOLD:
 rv = avc_cache_threshold;
 break;
-- 
2.20.1

[PATCH v2 04/10] xsm: convert xsm_ops hook calls to alternative call

[Daniel P. Smith]

To reduce retpolines convert all the pointer function calls of the
xsm_ops hooks over to the alternative_call infrastructure.

Signed-off-by: Daniel P. Smith 
---
 xen/include/xsm/xsm.h | 195 +-
 1 file changed, 99 insertions(+), 96 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index a8805f514b..a39b5dc42f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -15,6 +15,9 @@
 #ifndef __XSM_H__
 #define __XSM_H__
 
+#ifdef CONFIG_XSM
+#include 
+#endif
 #include 
 #include 
 
@@ -198,288 +201,288 @@ extern struct xsm_operations xsm_ops;
 static inline void xsm_security_domaininfo (struct domain *d,
 struct xen_domctl_getdomaininfo *info)
 {
-xsm_ops.security_domaininfo(d, info);
+alternative_vcall(xsm_ops.security_domaininfo, d, info);
 }
 
 static inline int xsm_domain_create (xsm_default_t def, struct domain *d, u32 
ssidref)
 {
-return xsm_ops.domain_create(d, ssidref);
+return alternative_call(xsm_ops.domain_create, d, ssidref);
 }
 
 static inline int xsm_getdomaininfo (xsm_default_t def, struct domain *d)
 {
-return xsm_ops.getdomaininfo(d);
+return alternative_call(xsm_ops.getdomaininfo, d);
 }
 
 static inline int xsm_domctl_scheduler_op (xsm_default_t def, struct domain 
*d, int cmd)
 {
-return xsm_ops.domctl_scheduler_op(d, cmd);
+return alternative_call(xsm_ops.domctl_scheduler_op, d, cmd);
 }
 
 static inline int xsm_sysctl_scheduler_op (xsm_default_t def, int cmd)
 {
-return xsm_ops.sysctl_scheduler_op(cmd);
+return alternative_call(xsm_ops.sysctl_scheduler_op, cmd);
 }
 
 static inline int xsm_set_target (xsm_default_t def, struct domain *d, struct 
domain *e)
 {
-return xsm_ops.set_target(d, e);
+return alternative_call(xsm_ops.set_target, d, e);
 }
 
 static inline int xsm_domctl (xsm_default_t def, struct domain *d, int cmd)
 {
-return xsm_ops.domctl(d, cmd);
+return alternative_call(xsm_ops.domctl, d, cmd);
 }
 
 static inline int xsm_sysctl (xsm_default_t def, int cmd)
 {
-return xsm_ops.sysctl(cmd);
+return alternative_call(xsm_ops.sysctl, cmd);
 }
 
 static inline int xsm_readconsole (xsm_default_t def, uint32_t clear)
 {
-return xsm_ops.readconsole(clear);
+return alternative_call(xsm_ops.readconsole, clear);
 }
 
 static inline int xsm_evtchn_unbound (xsm_default_t def, struct domain *d1, 
struct evtchn *chn,
 domid_t 
id2)
 {
-return xsm_ops.evtchn_unbound(d1, chn, id2);
+return alternative_call(xsm_ops.evtchn_unbound, d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain (xsm_default_t def, struct domain *d1,
 struct evtchn *chan1, struct domain *d2, struct evtchn *chan2)
 {
-return xsm_ops.evtchn_interdomain(d1, chan1, d2, chan2);
+return alternative_call(xsm_ops.evtchn_interdomain, d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-xsm_ops.evtchn_close_post(chn);
+alternative_vcall(xsm_ops.evtchn_close_post, chn);
 }
 
 static inline int xsm_evtchn_send (xsm_default_t def, struct domain *d, struct 
evtchn *chn)
 {
-return xsm_ops.evtchn_send(d, chn);
+return alternative_call(xsm_ops.evtchn_send, d, chn);
 }
 
 static inline int xsm_evtchn_status (xsm_default_t def, struct domain *d, 
struct evtchn *chn)
 {
-return xsm_ops.evtchn_status(d, chn);
+return alternative_call(xsm_ops.evtchn_status, d, chn);
 }
 
 static inline int xsm_evtchn_reset (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops.evtchn_reset(d1, d2);
+return alternative_call(xsm_ops.evtchn_reset, d1, d2);
 }
 
 static inline int xsm_grant_mapref (xsm_default_t def, struct domain *d1, 
struct domain *d2,
 uint32_t flags)
 {
-return xsm_ops.grant_mapref(d1, d2, flags);
+return alternative_call(xsm_ops.grant_mapref, d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops.grant_unmapref(d1, d2);
+return alternative_call(xsm_ops.grant_unmapref, d1, d2);
 }
 
 static inline int xsm_grant_setup (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops.grant_setup(d1, d2);
+return alternative_call(xsm_ops.grant_setup, d1, d2);
 }
 
 static inline int xsm_grant_transfer (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xsm_ops.grant_transfer(d1, d2);
+return alternative_call(xsm_ops.grant_transfer, d1, d2);
 }
 
 static inline int xsm_grant_copy (xsm_default_t def, struct domain *d1, struct 
domain *d2)
 {
-return xsm_ops.grant_copy(d1, d2);
+return alternative_call(xsm_ops.grant_copy, d1, d2);
 }
 
 static inline int xsm_grant_query_size (xsm_default_t def, struct domain *d1, 
struct domain *d2)
 {
-return xs

[PATCH v2 05/10] xsm: decouple xsm header inclusion selection

[Daniel P. Smith]

Multiple preprocessor defines were used as a mechanism to selective
include parts of the xsm.h header file. This makes it difficult to know
which portion is being included at anyone time. This commit works to
simplify this by separating the core structure and functions of XSM into
xsm-core.h away from the wrapper functions which remain in xsm.h and
dummy.h.

Signed-off-by: Daniel P. Smith 
---
 xen/include/xsm/dummy.h|   2 +-
 xen/include/xsm/xsm-core.h | 263 +
 xen/include/xsm/xsm.h  | 241 +
 xen/xsm/dummy.c|   1 -
 xen/xsm/silo.c |   1 -
 5 files changed, 265 insertions(+), 243 deletions(-)
 create mode 100644 xen/include/xsm/xsm-core.h

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 363c6d7798..c445c5681b 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -16,7 +16,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 
 /* Cannot use BUILD_BUG_ON here because the expressions we check are not
diff --git a/xen/include/xsm/xsm-core.h b/xen/include/xsm/xsm-core.h
new file mode 100644
index 00..4f5e7a7d17
--- /dev/null
+++ b/xen/include/xsm/xsm-core.h
@@ -0,0 +1,263 @@
+/*
+ *  This file contains the XSM hook definitions for Xen.
+ *
+ *  This work is based on the LSM implementation in Linux 2.6.13.4.
+ *
+ *  Author:  George Coker, 
+ *
+ *  Contributors: Michael LeMay, 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2,
+ *  as published by the Free Software Foundation.
+ */
+
+#ifndef __XSM_CORE_H__
+#define __XSM_CORE_H__
+
+#include 
+#include 
+
+typedef void xsm_op_t;
+DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
+
+/* policy magic number (defined by XSM_MAGIC) */
+typedef u32 xsm_magic_t;
+
+#ifdef CONFIG_XSM_FLASK
+#define XSM_MAGIC 0xf97cff8c
+#else
+#define XSM_MAGIC 0x0
+#endif
+
+/* These annotations are used by callers and in dummy.h to document the
+ * default actions of XSM hooks. They should be compiled out otherwise.
+ */
+enum xsm_default {
+XSM_HOOK, /* Guests can normally access the hypercall */
+XSM_DM_PRIV,  /* Device model can perform on its target domain */
+XSM_TARGET,   /* Can perform on self or your target domain */
+XSM_PRIV, /* Privileged - normally restricted to dom0 */
+XSM_XS_PRIV,  /* Xenstore domain - can do some privileged operations */
+XSM_OTHER /* Something more complex */
+};
+typedef enum xsm_default xsm_default_t;
+
+struct xsm_operations {
+void (*security_domaininfo) (struct domain *d,
+struct xen_domctl_getdomaininfo *info);
+int (*domain_create) (struct domain *d, u32 ssidref);
+int (*getdomaininfo) (struct domain *d);
+int (*domctl_scheduler_op) (struct domain *d, int op);
+int (*sysctl_scheduler_op) (int op);
+int (*set_target) (struct domain *d, struct domain *e);
+int (*domctl) (struct domain *d, int cmd);
+int (*sysctl) (int cmd);
+int (*readconsole) (uint32_t clear);
+
+int (*evtchn_unbound) (struct domain *d, struct evtchn *chn, domid_t id2);
+int (*evtchn_interdomain) (struct domain *d1, struct evtchn *chn1,
+struct domain *d2, struct evtchn 
*chn2);
+void (*evtchn_close_post) (struct evtchn *chn);
+int (*evtchn_send) (struct domain *d, struct evtchn *chn);
+int (*evtchn_status) (struct domain *d, struct evtchn *chn);
+int (*evtchn_reset) (struct domain *d1, struct domain *d2);
+
+int (*grant_mapref) (struct domain *d1, struct domain *d2, uint32_t flags);
+int (*grant_unmapref) (struct domain *d1, struct domain *d2);
+int (*grant_setup) (struct domain *d1, struct domain *d2);
+int (*grant_transfer) (struct domain *d1, struct domain *d2);
+int (*grant_copy) (struct domain *d1, struct domain *d2);
+int (*grant_query_size) (struct domain *d1, struct domain *d2);
+
+int (*alloc_security_domain) (struct domain *d);
+void (*free_security_domain) (struct domain *d);
+int (*alloc_security_evtchns) (struct evtchn chn[], unsigned int nr);
+void (*free_security_evtchns) (struct evtchn chn[], unsigned int nr);
+char *(*show_security_evtchn) (struct domain *d, const struct evtchn *chn);
+int (*init_hardware_domain) (struct domain *d);
+
+int (*get_pod_target) (struct domain *d);
+int (*set_pod_target) (struct domain *d);
+int (*memory_exchange) (struct domain *d);
+int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
+int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
+int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct 
page_info *page);
+int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
+int (*map_gmfn_foreign) (struct domain *d, struct domain

[PATCH v2 06/10] xsm: enable xsm to always be included

[Daniel P. Smith]

The only difference between !CONFIG_XSM and CONFIG_XSM when SILO and FLASK are
not enabled is whether the XSM hooks in dummy.h are called as static inline
functions or as function pointers to static functions. As such this commit,

 * eliminates CONFIG_XSM
 * introduces CONFIG_XSM_EVTCHN_LABELING as replacement for enabling event
   channel labels
 * makes CONFIG_XSM_SILO AND CONFIG_XSM_FLASK default to no

Signed-off-by: Daniel P. Smith 
---
 xen/common/Kconfig|  51 
 xen/include/xen/sched.h   |   2 +-
 xen/include/xsm/xsm-core.h|  26 
 xen/include/xsm/xsm.h |   8 --
 xen/xsm/Makefile  |   4 +-
 xen/xsm/dummy.c   |   4 +-
 xen/{include => }/xsm/dummy.h | 220 --
 xen/xsm/silo.c|  17 +--
 xen/xsm/xsm_core.c|   4 -
 9 files changed, 141 insertions(+), 195 deletions(-)
 rename xen/{include => }/xsm/dummy.h (63%)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 1594ce4e73..3b50391392 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -200,23 +200,20 @@ config XENOPROF
 
  If unsure, say Y.
 
-config XSM
-   bool "Xen Security Modules support"
-   default ARM
-   ---help---
- Enables the security framework known as Xen Security Modules which
- allows administrators fine-grained control over a Xen domain and
- its capabilities by defining permissible interactions between domains,
- the hypervisor itself, and related resources such as memory and
- devices.
+menu "Xen Security Modules"
 
- If unsure, say N.
+config XSM_EVTCHN_LABELING
+   bool "Enables security labeling of event channels"
+   default n
+   help
+ This enables an XSM module to label and enforce access control over
+ event channels.
 
 config XSM_FLASK
-   def_bool y
-   prompt "FLux Advanced Security Kernel support"
-   depends on XSM
-   ---help---
+   bool "FLux Advanced Security Kernel support"
+   default n
+   select XSM_EVTCHN_LABELING
+   help
  Enables FLASK (FLux Advanced Security Kernel) as the access control
  mechanism used by the XSM framework.  This provides a mandatory access
  control framework by which security enforcement, isolation, and
@@ -226,10 +223,10 @@ config XSM_FLASK
  If unsure, say Y.
 
 config XSM_FLASK_AVC_STATS
-   def_bool y
-   prompt "Maintain statistics on the FLASK access vector cache" if EXPERT
+   bool "Maintain statistics on the FLASK access vector cache" if EXPERT
+   default y
depends on XSM_FLASK
-   ---help---
+   help
  Maintain counters on the access vector cache that can be viewed using
  the FLASK_AVC_CACHESTATS sub-op of the xsm_op hypercall.  Disabling
  this will save a tiny amount of memory and time to update the stats.
@@ -240,7 +237,7 @@ config XSM_FLASK_POLICY
bool "Compile Xen with a built-in FLASK security policy"
default y if "$(XEN_HAS_CHECKPOLICY)" = "y"
depends on XSM_FLASK
-   ---help---
+   help
  This includes a default XSM policy in the hypervisor so that the
  bootloader does not need to load a policy to get sane behavior from an
  XSM-enabled hypervisor.  If this is disabled, a policy must be
@@ -253,10 +250,10 @@ config XSM_FLASK_POLICY
  If unsure, say Y.
 
 config XSM_SILO
-   def_bool y
-   prompt "SILO support"
-   depends on XSM
-   ---help---
+   bool "SILO support"
+   default y if ARM
+   default n
+   help
  Enables SILO as the access control mechanism used by the XSM 
framework.
  This is not the default module, add boot parameter xsm=silo to choose
  it. This will deny any unmediated communication channels (grant tables
@@ -265,24 +262,26 @@ config XSM_SILO
  If unsure, say Y.
 
 choice
-   prompt "Default XSM implementation"
-   depends on XSM
+   prompt "Default XSM module"
default XSM_SILO_DEFAULT if XSM_SILO && ARM
default XSM_FLASK_DEFAULT if XSM_FLASK
default XSM_SILO_DEFAULT if XSM_SILO
default XSM_DUMMY_DEFAULT
config XSM_DUMMY_DEFAULT
-   bool "Match non-XSM behavior"
+   bool "Classic Dom0 behavior"
config XSM_FLASK_DEFAULT
bool "FLux Advanced Security Kernel" if XSM_FLASK
config XSM_SILO_DEFAULT
bool "SILO" if XSM_SILO
+
 endchoice
 
+endmenu
+
 config LATE_HWDOM
bool "Dedicated hardware domain"
default n
-   depends on XSM && X86
+   depends on XSM_FLASK && X86
---help---
  Allows the creation of a dedicated hardware domain distinct from
  domain 0 that manages devices without needing access to other
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 28146ee404..aecf0b8424 100644
--- a/xen/incl

[PATCH v2 07/10] xsm: drop generic event channel labeling

[Daniel P. Smith]

The generic event channel labeling has not been used by any XSM module since
its introduction. This commit removes the capability leaving FLASK labeling
field always present. In the future if a new XSM module needs to have its own
channel label, this or a new form can be introduced.
---
 xen/common/Kconfig  | 8 
 xen/include/xen/sched.h | 9 -
 2 files changed, 17 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3b50391392..d03a991183 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -202,17 +202,9 @@ config XENOPROF
 
 menu "Xen Security Modules"
 
-config XSM_EVTCHN_LABELING
-   bool "Enables security labeling of event channels"
-   default n
-   help
- This enables an XSM module to label and enforce access control over
- event channels.
-
 config XSM_FLASK
bool "FLux Advanced Security Kernel support"
default n
-   select XSM_EVTCHN_LABELING
help
  Enables FLASK (FLux Advanced Security Kernel) as the access control
  mechanism used by the XSM framework.  This provides a mandatory access
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index aecf0b8424..ef6ba6d791 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -120,15 +120,7 @@ struct evtchn
 unsigned short notify_vcpu_id; /* VCPU for local delivery notification */
 uint32_t fifo_lastq;   /* Data for identifying last queue. */
 
-#ifdef CONFIG_XSM_EVTCHN_LABELING
 union {
-#ifdef XSM_NEED_GENERIC_EVTCHN_SSID
-/*
- * If an XSM module needs more space for its event channel context,
- * this pointer stores the necessary data for the security server.
- */
-void *generic;
-#endif
 #ifdef CONFIG_XSM_FLASK
 /*
  * Inlining the contents of the structure for FLASK avoids unneeded
@@ -138,7 +130,6 @@ struct evtchn
 uint32_t flask_sid;
 #endif
 } ssid;
-#endif
 } __attribute__((aligned(64)));
 
 int  evtchn_init(struct domain *d, unsigned int max_port);
-- 
2.20.1

[PATCH v2 08/10] xsm: remove xsm_default_t from hook definitions

[Daniel P. Smith]

The passing of an xsm_default_t at each of the xsm hook call sites
served different functions depending on whether XSM was enabled or not.
When XSM was not enabled it attempted to function as a link-time check
that declared default action at the call site matched the default
declared action for that hook in the dummy policy. When XSM was enabled,
it would just drop the  parameter.

The removal of these values is two fold. They are a redundancy that
provides little context, especially when the value is XSM_OTHER.  A more
appropriate approach is that the hook functions in the dummy policy
should provide reasoning of the default value when it is not clear. Next
is that with the change to make XSM always enabled is the case where the
parameter is completely ignored. Thus it is logical to remove them from
the hook call sites.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/arm/dm.c |   2 +-
 xen/arch/arm/domctl.c |   6 +-
 xen/arch/arm/hvm.c|   2 +-
 xen/arch/arm/mm.c |   2 +-
 xen/arch/arm/platform_hypercall.c |   2 +-
 xen/arch/x86/cpu/mcheck/mce.c |   2 +-
 xen/arch/x86/cpu/vpmu.c   |   2 +-
 xen/arch/x86/domctl.c |   8 +-
 xen/arch/x86/hvm/dm.c |   2 +-
 xen/arch/x86/hvm/hvm.c|  12 +-
 xen/arch/x86/irq.c|   5 +-
 xen/arch/x86/mm.c |  20 +--
 xen/arch/x86/mm/mem_paging.c  |   2 +-
 xen/arch/x86/mm/mem_sharing.c |   9 +-
 xen/arch/x86/mm/p2m.c |   2 +-
 xen/arch/x86/mm/paging.c  |   4 +-
 xen/arch/x86/mm/shadow/set.c  |   2 +-
 xen/arch/x86/msi.c|   3 +-
 xen/arch/x86/pci.c|   2 +-
 xen/arch/x86/physdev.c|  17 ++-
 xen/arch/x86/platform_hypercall.c |  10 +-
 xen/arch/x86/pv/emul-priv-op.c|   2 +-
 xen/arch/x86/sysctl.c |   4 +-
 xen/common/domain.c   |   4 +-
 xen/common/domctl.c   |  12 +-
 xen/common/event_channel.c|  12 +-
 xen/common/grant_table.c  |  16 +--
 xen/common/hypfs.c|   2 +-
 xen/common/kernel.c   |   2 +-
 xen/common/kexec.c|   2 +-
 xen/common/mem_access.c   |   2 +-
 xen/common/memory.c   |  16 +--
 xen/common/monitor.c  |   2 +-
 xen/common/sched/core.c   |   6 +-
 xen/common/sysctl.c   |   8 +-
 xen/common/vm_event.c |   2 +-
 xen/common/xenoprof.c |   2 +-
 xen/drivers/char/console.c|   2 +-
 xen/drivers/passthrough/device_tree.c |   4 +-
 xen/drivers/passthrough/pci.c |  12 +-
 xen/include/xsm/xsm.h | 172 +-
 41 files changed, 197 insertions(+), 203 deletions(-)

diff --git a/xen/arch/arm/dm.c b/xen/arch/arm/dm.c
index 1b3fd6bc7d..c8b89c8f47 100644
--- a/xen/arch/arm/dm.c
+++ b/xen/arch/arm/dm.c
@@ -45,7 +45,7 @@ int dm_op(const struct dmop_args *op_args)
 if ( rc )
 return rc;
 
-rc = xsm_dm_op(XSM_DM_PRIV, d);
+rc = xsm_dm_op(d);
 if ( rc )
 goto out;
 
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index b7d27f37df..e7202703ee 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -95,11 +95,11 @@ long arch_do_domctl(struct xen_domctl *domctl, struct 
domain *d,
  * done by the 2 hypercalls for consistency with other
  * architectures.
  */
-rc = xsm_map_domain_irq(XSM_HOOK, d, irq, NULL);
+rc = xsm_map_domain_irq(d, irq, NULL);
 if ( rc )
 return rc;
 
-rc = xsm_bind_pt_irq(XSM_HOOK, d, bind);
+rc = xsm_bind_pt_irq(d, bind);
 if ( rc )
 return rc;
 
@@ -130,7 +130,7 @@ long arch_do_domctl(struct xen_domctl *domctl, struct 
domain *d,
 if ( irq != virq )
 return -EINVAL;
 
-rc = xsm_unbind_pt_irq(XSM_HOOK, d, bind);
+rc = xsm_unbind_pt_irq(d, bind);
 if ( rc )
 return rc;
 
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index 8951b34086..cf4bd9ae09 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -101,7 +101,7 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( d == NULL )
 return -ESRCH;
 
-rc = xsm_hvm_param(XSM_TARGET, d, op);
+rc = xsm_hvm_param(d, op);
 if ( rc )
 goto param_fail;
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0e07335291..a256c89b62 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1446,7 +1446,7 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+rc = xsm_map_gmfn_foreign(d, od);
 if ( rc )
 {
 put_pg_owner(od);
diff --git a/xen/arch/arm/pla

[PATCH v2 09/10] xsm: expand the function related macros in dummy.h

[Daniel P. Smith]

With the elimination of switching how dummy.h gets included, the function
declaration macros are no longer necessary. This commit expands them out to the
only value for which they will ever be set. This results in function
declaration lengths changing and since some definitions did not even follow the
80 column wrapping style, all function definitions were aligned with the
predominate style found in core hypervisor code.

Signed-off-by: Daniel P. Smith 
---
 xen/xsm/dummy.h | 275 +++-
 1 file changed, 153 insertions(+), 122 deletions(-)

diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
index a3e698c3b5..1cb26e4146 100644
--- a/xen/xsm/dummy.h
+++ b/xen/xsm/dummy.h
@@ -9,7 +9,7 @@
  *
  *
  *  Each XSM hook implementing an access check should have its first parameter
- *  preceded by XSM_DEFAULT_ARG (or use XSM_DEFAULT_VOID if it has no
+ *  preceded by (or use XSM_DEFAULT_VOID if it has no
  *  arguments). The first non-declaration statement shold be XSM_ASSERT_ACTION
  *  with the expected type of the hook, which will either define or check the
  *  value of action.
@@ -47,14 +47,11 @@ void __xsm_action_mismatch_detected(void);
  * xsm_default_t argument available, so the value from the assertion is used to
  * initialize the variable.
  */
-#define XSM_INLINE __maybe_unused
-
-#define XSM_DEFAULT_ARG /* */
-#define XSM_DEFAULT_VOID void
 #define XSM_ASSERT_ACTION(def) xsm_default_t action = def; (void)action
 
-static always_inline int xsm_default_action(
-xsm_default_t action, struct domain *src, struct domain *target)
+static always_inline int xsm_default_action(xsm_default_t action,
+struct domain *src,
+struct domain *target)
 {
 switch ( action ) {
 case XSM_HOOK:
@@ -82,43 +79,43 @@ static always_inline int xsm_default_action(
 }
 }
 
-static XSM_INLINE void dummy_security_domaininfo(struct domain *d,
+static inline void dummy_security_domaininfo(struct domain *d,
 struct xen_domctl_getdomaininfo *info)
 {
 return;
 }
 
-static XSM_INLINE int dummy_domain_create(XSM_DEFAULT_ARG struct domain *d, 
u32 ssidref)
+static inline int dummy_domain_create(struct domain *d, u32 ssidref)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, d);
 }
 
-static XSM_INLINE int dummy_getdomaininfo(XSM_DEFAULT_ARG struct domain *d)
+static inline int dummy_getdomaininfo(struct domain *d)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, d);
 }
 
-static XSM_INLINE int dummy_domctl_scheduler_op(XSM_DEFAULT_ARG struct domain 
*d, int cmd)
+static inline int dummy_domctl_scheduler_op(struct domain *d, int cmd)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, d);
 }
 
-static XSM_INLINE int dummy_sysctl_scheduler_op(XSM_DEFAULT_ARG int cmd)
+static inline int dummy_sysctl_scheduler_op(int cmd)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, NULL);
 }
 
-static XSM_INLINE int dummy_set_target(XSM_DEFAULT_ARG struct domain *d, 
struct domain *e)
+static inline int dummy_set_target(struct domain *d, struct domain *e)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, NULL);
 }
 
-static XSM_INLINE int dummy_domctl(XSM_DEFAULT_ARG struct domain *d, int cmd)
+static inline int dummy_domctl(struct domain *d, int cmd)
 {
 XSM_ASSERT_ACTION(XSM_OTHER);
 switch ( cmd )
@@ -135,85 +132,91 @@ static XSM_INLINE int dummy_domctl(XSM_DEFAULT_ARG struct 
domain *d, int cmd)
 }
 }
 
-static XSM_INLINE int dummy_sysctl(XSM_DEFAULT_ARG int cmd)
+static inline int dummy_sysctl(int cmd)
 {
 XSM_ASSERT_ACTION(XSM_PRIV);
 return xsm_default_action(action, current->domain, NULL);
 }
 
-static XSM_INLINE int dummy_readconsole(XSM_DEFAULT_ARG uint32_t clear)
+static inline int dummy_readconsole(uint32_t clear)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, NULL);
 }
 
-static XSM_INLINE int dummy_alloc_security_domain(struct domain *d)
+static inline int dummy_alloc_security_domain(struct domain *d)
 {
 return 0;
 }
 
-static XSM_INLINE void dummy_free_security_domain(struct domain *d)
+static inline void dummy_free_security_domain(struct domain *d)
 {
 return;
 }
 
-static XSM_INLINE int dummy_grant_mapref(XSM_DEFAULT_ARG struct domain *d1, 
struct domain *d2,
-uint32_t flags)
+static inline int dummy_grant_mapref(struct domain *d1,
+ struct domain *d2,
+ uint32_t flags)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, d1, d2);
 }
 
-static XSM_INLINE int dummy_grant_unmapref(XSM_DEFAULT_ARG struct doma

[PATCH v2 10/10] xsm: removing the XSM_ASSERT_ACTION macro

[Daniel P. Smith]

With the eliminations of default priv from all the XSM hook call sites, this
renders the XSM_ASSERT_ACTION macro unneeded. This commit cleans up all the
dummy hooks, removing the macro.

Signed-off-by: Daniel P. Smith 
---
 xen/xsm/dummy.h | 253 +++-
 1 file changed, 80 insertions(+), 173 deletions(-)

diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
index 1cb26e4146..1aaec86b05 100644
--- a/xen/xsm/dummy.h
+++ b/xen/xsm/dummy.h
@@ -6,13 +6,6 @@
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License version 2,
  *  as published by the Free Software Foundation.
- *
- *
- *  Each XSM hook implementing an access check should have its first parameter
- *  preceded by (or use XSM_DEFAULT_VOID if it has no
- *  arguments). The first non-declaration statement shold be XSM_ASSERT_ACTION
- *  with the expected type of the hook, which will either define or check the
- *  value of action.
  */
 
 #include 
@@ -47,7 +40,6 @@ void __xsm_action_mismatch_detected(void);
  * xsm_default_t argument available, so the value from the assertion is used to
  * initialize the variable.
  */
-#define XSM_ASSERT_ACTION(def) xsm_default_t action = def; (void)action
 
 static always_inline int xsm_default_action(xsm_default_t action,
 struct domain *src,
@@ -87,37 +79,31 @@ static inline void dummy_security_domaininfo(struct domain 
*d,
 
 static inline int dummy_domain_create(struct domain *d, u32 ssidref)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, current->domain, d);
+return xsm_default_action(XSM_HOOK, current->domain, d);
 }
 
 static inline int dummy_getdomaininfo(struct domain *d)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, current->domain, d);
+return xsm_default_action(XSM_HOOK, current->domain, d);
 }
 
 static inline int dummy_domctl_scheduler_op(struct domain *d, int cmd)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, current->domain, d);
+return xsm_default_action(XSM_HOOK, current->domain, d);
 }
 
 static inline int dummy_sysctl_scheduler_op(int cmd)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, current->domain, NULL);
+return xsm_default_action(XSM_HOOK, current->domain, NULL);
 }
 
 static inline int dummy_set_target(struct domain *d, struct domain *e)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, current->domain, NULL);
+return xsm_default_action(XSM_HOOK, current->domain, NULL);
 }
 
 static inline int dummy_domctl(struct domain *d, int cmd)
 {
-XSM_ASSERT_ACTION(XSM_OTHER);
 switch ( cmd )
 {
 case XEN_DOMCTL_ioport_mapping:
@@ -134,14 +120,12 @@ static inline int dummy_domctl(struct domain *d, int cmd)
 
 static inline int dummy_sysctl(int cmd)
 {
-XSM_ASSERT_ACTION(XSM_PRIV);
-return xsm_default_action(action, current->domain, NULL);
+return xsm_default_action(XSM_PRIV, current->domain, NULL);
 }
 
 static inline int dummy_readconsole(uint32_t clear)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, current->domain, NULL);
+return xsm_default_action(XSM_HOOK, current->domain, NULL);
 }
 
 static inline int dummy_alloc_security_domain(struct domain *d)
@@ -158,67 +142,57 @@ static inline int dummy_grant_mapref(struct domain *d1,
  struct domain *d2,
  uint32_t flags)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, d1, d2);
+return xsm_default_action(XSM_HOOK, d1, d2);
 }
 
 static inline int dummy_grant_unmapref(struct domain *d1,
struct domain *d2)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, d1, d2);
+return xsm_default_action(XSM_HOOK, d1, d2);
 }
 
 static inline int dummy_grant_setup(struct domain *d1,
 struct domain *d2)
 {
-XSM_ASSERT_ACTION(XSM_TARGET);
-return xsm_default_action(action, d1, d2);
+return xsm_default_action(XSM_TARGET, d1, d2);
 }
 
 static inline int dummy_grant_transfer(struct domain *d1,
struct domain *d2)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, d1, d2);
+return xsm_default_action(XSM_HOOK, d1, d2);
 }
 
 static inline int dummy_grant_copy(struct domain *d1, struct domain *d2)
 {
-XSM_ASSERT_ACTION(XSM_HOOK);
-return xsm_default_action(action, d1, d2);
+return xsm_default_action(XSM_HOOK, d1, d2);
 }
 
 static inline int dummy_grant_query_size(struct domain *d1,
  struct domain *d2)
 {
-XSM_ASSERT_ACTION(XSM_TARGET);
-return xsm_default_action(action, d1, d2);
+return xsm_default_action(

Re: [Kvmtool] Some thoughts on using kvmtool Virtio for Xen

[Stefano Stabellini]

On Fri, 9 Jul 2021, Andre Przywara wrote:
> On Tue, 15 Jun 2021 07:12:08 +0100
> Wei Chen  wrote:
> 
> Hi Wei,
> 
> > I have some thoughts of using kvmtool Virtio implementation
> > for Xen. I copied my markdown file to this email. If you have
> > time, could you please help me review it?
> > 
> > Any feedback is welcome!
> > 
> > # Some thoughts on using kvmtool Virtio for Xen
> > ## Background
> > 
> > Xen community is working on adding VIRTIO capability to Xen. And we're 
> > working
> > on VIRTIO backend of Xen. But except QEMU can support virtio-net for 
> > x86-xen,
> > there is not any VIRTIO backend can support Xen. Because of the community's
> > strong voice of Out-of-QEMU, we want to find a light weight VIRTIO backend 
> > to
> > support Xen.
> > 
> > We have an idea of utilizing the virtio implementaton of kvmtool for Xen. 
> > And
> > We know there was some agreement that kvmtool won't try to be a full QEMU
> > alternative. So we have written two proposals in following content for
> > communities to discuss in public:
> > 
> > ## Proposals
> > ### 1. Introduce a new "dm-only" command
> > 1. Introduce a new "dm-only" command to provide a pure device model mode. In
> >this mode, kvmtool only handles IO request. VM creation and 
> > initialization
> >will be bypassed.
> > 
> > * We will rework the interface between the virtio code and the rest of
> > kvmtool, to use just the minimal set of information. At the end, there
> > would be MMIO accesses and shared memory that control the device model,
> > so that could be abstracted to do away with any KVM specifics at all. If
> > this is workable, we will send the first set of patches to introduce 
> > this
> > interface, and adapt the existing kvmtool to it. Then later we will can
> > add Xen support on top of it.
> > 
> > About Xen support, we will detect the presence of Xen libraries, also
> > allow people to ignore them, as kvmtoll do with optional features like
> > libz or libaio.
> > 
> > Idealy, we want to move all code replying on Xen libraries to a set of
> > new files. In this case, thes files can only be compiled when Xen
> > libraries are detected. But if we can't decouple this code completely,
> > we may introduce a bit of #ifdefs to protect this code.
> > 
> > If kvm or other VMM do not need "dm-only" mode. Or "dm-only" can not
> > work without Xen libraries. We will make "dm-only" command depends on
> > the presence of Xen libraries.
> > 
> > So a normal compile (without the Xen libraries installed) would create
> > a binary as close as possible to the current code, and only the people
> > who having Xen libraries installed would ever generate a "dm-only"
> > capable kvmtool.
> 
> This is not for me to decide, but just to let you know that this
> approach might not be very popular with kvmtool people, as kvmtool's
> design goal is be "lean and mean". So slapping a lot of code on the
> side, not helping with the actual KVM functionality, does not sound too
> tempting.
> 
> > 
> > ### 2. Abstract kvmtool virtio implementation as a library
> > 1. Add a kvmtool Makefile target to generate a virtio library. In this
> >scenario, not just Xen, but any project else want to provide a
> >userspace virtio backend service can link to this virtio libraris.
> >These users would benefit from the VIRTIO implementation of kvmtool
> >and will participate in improvements, upgrades, and maintenance of
> >the VIRTIO libraries.
> > 
> > * In this case, Xen part code will not upstream to kvmtool repo,
> >   it would then be natural parts of the xen repo, in xen/tools or
> >   maintained in other repo.
> > 
> >   We will have a completely separate VIRTIO backend for Xen, just
> >   linking to kvmtool's VIRTIO library.
> > 
> > * The main changes of kvmtool would be:
> > 1. Still need to rework the interface between the virtio code
> >and the rest of kvmtool, to abstract the whole virtio
> >implementation into a library
> > 2. Modify current build system to add a new virtio library target.
> 
> As this has at least the prospect of being cleaner, this approach
> sounds better to me.

There are two sets of changes:

a) Xen ioreq handling
b) introducing map_guest_page/unmap_guest_page and abstracting other
   hypervisor interfaces 

a) is minimal and b) is more invasive. The problem is b) is required
regardless, so the library approach wouldn't really help much with
reducing the amount of changes required for this to work. But yes, it
might be cleaner.

[xen-unstable-smoke test] 163614: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 163474

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  93c9edbef51b31056f93a37a778326c90a83158c
baseline version:
 xen  6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf

Last test of basis   163474  2021-07-09 12:00:25 Z3 days
Failing since163480  2021-07-09 16:08:01 Z3 days   19 attempts
Testing same since   163489  2021-07-09 21:00:27 Z3 days   18 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Costin Lupu 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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
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


Not pushing.


commit 93c9edbef51b31056f93a37a778326c90a83158c
Author: Andrew Cooper 
Date:   Tue Jun 15 16:02:29 2021 +0100

tests/xenstore: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

This causes the code to be noticed by CI, which objects as follows:

  test-xenstore.c: In function 'main':
  test-xenstore.c:486:5: error: ignoring return value of 'asprintf', 
declared
  with attribute warn_unused_result [-Werror=unused-result]
   asprintf(&path, "%s/%u", TEST_PATH, getpid());
   ^

Address the CI failure by checking the asprintf() return value and exiting.

Rename xs-test to test-xenstore to be consistent with other tests.  Honour
APPEND_FLAGS too.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 6a9f5477637a9f2d1d61c0a065eeb01bf84f6484
Author: Andrew Cooper 
Date:   Tue Jun 15 15:37:49 2021 +0100

tests/cpu-policy: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Rework TARGET-y to be TARGETS, drop redundant -f's for $(RM), drop the
unconditional -O3 and use the default instead, and drop CFLAGS from the link
line but honour APPEND_LDFLAGS.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit ff759953b32286f376fda7f3ff5a17eccb542b03
Author: Andrew Cooper 
Date:   Tue Jun 15 15:22:11 2021 +0100

tests/resource: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Make all object files depend on the Makefile, drop redundant -f's for $(RM),
and use $(TARGET) when appropriate.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 79ca512a1fa68e0170a85cb71b8a8e8f4a34fb11
Author: Andrew Cooper 
Date:   Tue Jun 15 14:19:15 2021 +0100

tools/tests: Drop obsolete mce-test infrastructure

mce-test has a test suite, but it depends on xend, needs to run in-tree, and
requires manual setup of at least one guest, and manual parameters to pass
into cases.  Drop th

[linux-linus test] 163597: regressions - FAIL

[osstest service owner]

flight 163597 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163597/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-examine   6 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332
 test-amd64-i386-libvirt   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-i386-xl7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-freebsd10-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-raw7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-pvshim 7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-shadow 7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-freebsd10-i386  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-coresched-i386-xl  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt-xsm   7 xen-install  fail REGR. vs. 152332
 test-amd64-amd64-libvirt-vhd 13 guest-start  fail REGR. vs. 152332
 test-arm64-arm64-xl-credit1  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl-credit2  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl-xsm  13 debian-fixup fail REGR. vs. 152332
 test-amd64-amd64-amd64-pvgrub 20 guest-stop  fail REGR. vs. 152332
 test-arm64-arm64-xl-thunderx 14 guest-start  fail REGR. vs. 152332
 test-arm64-arm64-xl  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-libvirt-xsm 14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-i386-pvgrub 20 guest-stop   fail REGR. vs. 152332
 test-armhf-armhf-libvirt  8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-libvirt-raw  8 xen-boot fail REGR. vs. 152332
 test-amd64-amd64-xl-qcow213 guest-start  fail REGR. vs. 152332
 test-armhf-armhf-xl-multivcpu  8 xen-bootfail REGR. vs. 152332
 test-armhf-armhf-xl   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl-credit2   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl-credit1   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl-vhd  13 guest-start  fail REGR. vs. 152332
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 152332
 test-armhf-armhf-xl-arndale   8 xen-boot fail REGR. vs. 152332

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10   fail REGR. vs. 152332
 test-armhf-armhf-xl-rtds  8 xen-boot fail REGR. vs. 152332

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332
 test-arm

Re: [PATCH v2 00/10] xsm: refactoring xsm hooks

[Andrew Cooper]

On 12/07/2021 21:32, Daniel P. Smith wrote:
> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
> patch set is being split into two separate patch sets. This is the first
> patch set and is focused purely on the clean up and refactoring of the
> XSM hooks.
>
> This patch set refactors the xsm_ops wrapper hooks to use the alternative_call
> infrastructure. Then proceeds to move and realign the headers to remove the
> psuedo is/is not enable implementation. The remainder of the changes are 
> clean up
> and removing no longer necessary abstractions.
>
> v2:
>  - restructured the patches, breaking them up as needed
>  - incorporate Andrew Cooper's alternative call common code
>  - change XSM module registration, removing register_xsm
>  - incoporate KConfig recommendations
>  - reworded commit messages
>  - incorporate macro expansion recommendations
>  - misc clean-up fallout from recommendations

CI is heavily broken atm, but there is one issue I've spotted which is
introduced by this series.

https://gitlab.com/xen-project/patchew/xen/-/jobs/1418359368

In file included from xsm_policy.c:21:
/builds/xen-project/patchew/xen/xen/include/xsm/xsm.h: In function
'xsm_security_domaininfo':
/builds/xen-project/patchew/xen/xen/include/xsm/xsm.h:30:5: error:
implicit declaration of function 'alternative_vcall'
[-Werror=implicit-function-declaration]
   30 | alternative_vcall(xsm_ops.security_domaininfo, d, info);
  | ^


You need to drop the XSM guard around including xen/alternative-call.h
in patch 4, especially seeing as as you don't delete it in patch 6 where
CONFIG_XSM formally disappears.  The x86 build only works by chance,
with asm/alternative.h being included implicitly.

~Andrew

[qemu-mainline test] 163600: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 163321
 test-amd64-amd64-qemuu-freebsd12-amd64 13 guest-startfail REGR. vs. 163321
 test-amd64-i386-qemuu-rhel6hvm-amd 12 redhat-install fail REGR. vs. 163321
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 163321
 test-amd64-i386-freebsd10-i386 13 guest-startfail REGR. vs. 163321
 test-amd64-amd64-libvirt 14 guest-start  fail REGR. vs. 163321
 test-amd64-i386-freebsd10-amd64 13 guest-start   fail REGR. vs. 163321
 test-amd64-i386-libvirt-xsm  14 guest-start  fail REGR. vs. 163321
 test-amd64-i386-libvirt  14 guest-start  fail REGR. vs. 163321
 test-amd64-amd64-libvirt-pair 25 guest-start/debian  fail REGR. vs. 163321
 test-amd64-i386-libvirt-pair 25 guest-start/debian   fail REGR. vs. 163321
 test-amd64-amd64-qemuu-nested-amd 12 debian-hvm-install  fail REGR. vs. 163321
 test-amd64-i386-qemuu-rhel6hvm-intel 12 redhat-install   fail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install  fail REGR. vs. 163321
 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail REGR. vs. 163321
 test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
163321
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 163321
 test-arm64-arm64-libvirt-xsm 14 guest-start  fail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 163321
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
163321
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 163321
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 163321
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 163321
 test-amd64-amd64-xl-qcow212 debian-di-installfail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 
163321
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 163321
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 163321
 test-amd64-amd64-libvirt-vhd 12 debian-di-installfail REGR. vs. 163321
 test-amd64-i386-xl-qemuu-win7-amd64 12 windows-install   fail REGR. vs. 163321
 test-armhf-armhf-libvirt 14 guest-start  fail REGR. vs. 163321
 test-amd64-i386-xl-qemuu-ws16-amd64 12 windows-install   fail REGR. vs. 163321
 test-amd64-amd64-xl-qemuu-ws16-amd64 12 windows-install  fail REGR. vs. 163321
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 163321
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 163321

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-sup

Re: [PATCH v2 03/10] xsm: remove the ability to disable flask

[Andrew Cooper]

On 12/07/2021 21:32, Daniel P. Smith wrote:
> The flask XSM module provided the ability to switch from flask back to
> the dummy XSM module during runtime. With this removal the only way to
> switch between XSM modules is at boot time.
>
> Signed-off-by: Daniel P. Smith 

This patch wants reordering ahead of "xsm: refactor xsm_ops handling"
which will reduce the churn in that patch.

In addition, you want:

diff --git a/xen/include/public/xsm/flask_op.h
b/xen/include/public/xsm/flask_op.h
index 16af7bc22f75..b41dd6dac894 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -188,7 +188,7 @@ struct xen_flask_op {
 #define FLASK_SETBOOL   12
 #define FLASK_COMMITBOOLS   13
 #define FLASK_MLS   14
-#define FLASK_DISABLE   15
+#define FLASK_DISABLE   15 /* No longer implemented */
 #define FLASK_GETAVC_THRESHOLD  16
 #define FLASK_SETAVC_THRESHOLD  17
 #define FLASK_AVC_HASHSTATS 18

to match the removal of FLASK_USER in c/s 559f439bfa3bf

~Andrew

Re: [PATCH v2 02/10] xsm: refactor xsm_ops handling

[Andrew Cooper]

On 12/07/2021 21:32, Daniel P. Smith wrote:
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index ad3cddbf7d..a8805f514b 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -747,16 +747,14 @@ extern int xsm_dt_policy_init(void **policy_buffer, 
> size_t *policy_size);
>  extern bool has_xsm_magic(paddr_t);
>  #endif
>  
> -extern int register_xsm(struct xsm_operations *ops);
> -
> -extern struct xsm_operations dummy_xsm_ops;
>  extern void xsm_fixup_ops(struct xsm_operations *ops);
>  
>  #ifdef CONFIG_XSM_FLASK
> -extern void flask_init(const void *policy_buffer, size_t policy_size);
> +extern struct xsm_operations *flask_init(const void *policy_buffer, size_t 
> policy_size);
>  #else
> -static inline void flask_init(const void *policy_buffer, size_t policy_size)
> +static inline struct xsm_operations *flask_init(const void *policy_buffer, 
> size_t policy_size)
>  {
> +return NULL;
>  }
>  #endif

As you touch almost every current user of xsm_operations and introduce
quite a few more, can I recommend taking the opportunity to shorten the
name to struct xsm_ops.

> diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
> index 01e52138a1..32e079d676 100644
> --- a/xen/xsm/flask/flask_op.c
> +++ b/xen/xsm/flask/flask_op.c
> @@ -226,6 +226,7 @@ static int flask_security_sid(struct 
> xen_flask_sid_context *arg)
>  static int flask_disable(void)
>  {
>  static int flask_disabled = 0;
> +struct xsm_operations default_ops;
>  
>  if ( ss_initialized )
>  {
> @@ -244,7 +245,8 @@ static int flask_disable(void)
>  flask_disabled = 1;
>  
>  /* Reset xsm_ops to the original module. */
> -xsm_ops = &dummy_xsm_ops;
> +xsm_fixup_ops(&default_ops);
> +xsm_ops = default_ops;
>  
>  return 0;
>  }

These two hunks will disappear when patch 3 is reordered with respect to
this one.

... which is good because you've just pointed xsm_ops at a
soon-to-be-out-of-scope local variable on the stack.

> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index f1a1217c98..a3a88aa8ed 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1883,7 +1883,8 @@ static struct xsm_operations flask_ops = {
>  #endif
>  };

flask and silo ops should become:

static const struct xsm_ops __initconst {flask,silo}_ops = {

as they're neither modified, nor needed after init, following this change.

>  
> -void __init flask_init(const void *policy_buffer, size_t policy_size)
> +struct xsm_operations __init *flask_init(const void *policy_buffer,
> +  size_t policy_size)

struct xsm_ops *__init flask_init(...)

Otherwise you've got the __init in the middle of the return type, and
some compilers are more picky than others.

> @@ -1923,6 +1921,9 @@ void __init flask_init(const void *policy_buffer, 
> size_t policy_size)
>  printk(XENLOG_INFO "Flask:  Starting in enforcing mode.\n");
>  else
>  printk(XENLOG_INFO "Flask:  Starting in permissive mode.\n");
> +
> +return &flask_ops;
> +

Stray newline.

>  }
>  
>  /*
> diff --git a/xen/xsm/silo.c b/xen/xsm/silo.c
> index fc2ca5cd2d..808350f122 100644
> --- a/xen/xsm/silo.c
> +++ b/xen/xsm/silo.c
> @@ -112,12 +112,11 @@ static struct xsm_operations silo_xsm_ops = {
>  #endif
>  };
>  
> -void __init silo_init(void)
> +struct xsm_operations __init *silo_init(void)

Same here as with flask.

> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> index 5eab21e1b1..7265f742e9 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -68,17 +76,10 @@ static int __init parse_xsm_param(const char *s)
>  }
>  custom_param("xsm", parse_xsm_param);
>  
> -static inline int verify(struct xsm_operations *ops)
> -{
> -/* verify the security_operations structure exists */
> -if ( !ops )
> -return -EINVAL;
> -xsm_fixup_ops(ops);
> -return 0;
> -}
> -
>  static int __init xsm_core_init(const void *policy_buffer, size_t 
> policy_size)
>  {
> + struct xsm_operations *mod_ops;
> +

Hard tabs, and later in this function.  Also, how about just 'ops' for
the local variable name?

> @@ -113,6 +124,17 @@ static int __init xsm_core_init(const void 
> *policy_buffer, size_t policy_size)
>  break;
>  }
>  
> +/*
> + * This handles three cases,
> + *   - dummy policy module was selected
> + *   - a policy module  does not provide all handlers

Stray double space.

~Andrew

Re: [PATCH v2 04/10] xsm: convert xsm_ops hook calls to alternative call

[Andrew Cooper]

On 12/07/2021 21:32, Daniel P. Smith wrote:
> To reduce retpolines convert all the pointer function calls of the
> xsm_ops hooks over to the alternative_call infrastructure.
>
> Signed-off-by: Daniel P. Smith 
> ---
>  xen/include/xsm/xsm.h | 195 +-
>  1 file changed, 99 insertions(+), 96 deletions(-)
>
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index a8805f514b..a39b5dc42f 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -15,6 +15,9 @@
>  #ifndef __XSM_H__
>  #define __XSM_H__
>  
> +#ifdef CONFIG_XSM
> +#include 
> +#endif

This guard needs dropping to fix the build on ARM.

Otherwise, Acked-by: Andrew Cooper 

Re: [PATCH v2 01/10] xen: Implement xen/alternative-call.h for use in common code

[Andrew Cooper]

On 12/07/2021 21:32, Daniel P. Smith wrote:
> diff --git a/xen/include/xen/alternative-call.h 
> b/xen/include/xen/alternative-call.h
> new file mode 100644
> index 00..11d1c26068
> --- /dev/null
> +++ b/xen/include/xen/alternative-call.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef XEN_ALTERNATIVE_CALL
> +#define XEN_ALTERNATIVE_CALL
> +
> +/*
> + * Some subsystems in Xen may have multiple implementions, which can be
> + * resolved to a single implementation at boot time.  By default, this will
> + * result in the use of function pointers.
> + *
> + * Some architectures may have mechanisms for dynamically modifying .text.
> + * Using this mechnaism, function pointers can be converted to direct calls
> + * which are typically more efficient at runtime.
> + *
> + * For architectures to support:
> + *
> + * - Implement alternative_{,v}call() in asm/alternative.h.  Code generation
> + *   requirements are to emit a function pointer call at build time, and 
> stash
> + *   enough metadata to simplify the call at boot once the implementation has
> + *   been resolved.
> + * - Select ALTERNATIVE_CALL in Kconfig.
> + *
> + * To use:
> + *
> + * Consider the following simplified example.
> + *
> + *  1) struct foo_ops __alt_call_maybe_initdata ops;
> + *
> + *  2) struct foo_ops __alt_call_maybe_initconst foo_a_ops = { ... };
> + * struct foo_ops __alt_call_maybe_initconst foo_b_ops = { ... };

It occurs to me after reviewing patch 2 that these want to be const
struct foo_ops __initconst ..., and there is no need for
__alt_call_maybe_initconst at all.

The only thing wanting a conditional annotation like this is the single
ops object, and it needs to be initdata (or hopefully ro_after_init in
the future).

~Andrew

Re: [PATCH v2 07/10] xsm: drop generic event channel labeling

[Andrew Cooper]

On 12/07/2021 21:32, Daniel P. Smith wrote:
> The generic event channel labeling has not been used by any XSM module since
> its introduction. This commit removes the capability leaving FLASK labeling
> field always present. In the future if a new XSM module needs to have its own
> channel label, this or a new form can be introduced.

You're missing a SoB line.

Also, this too would benefit from being reordered higher than patch 6,
to reduce the churn there.

[PATCH v2] tools/libxc: use uint32_t for pirq in xc_domain_irq_permission

[Igor Druzhinin]

Current unit8_t for pirq argument in this interface is too restrictive
causing failures on modern hardware with lots of GSIs. That extends down to
XEN_DOMCTL_irq_permission ABI structure where it needs to be fixed up
as well.

Internal Xen structures appear to be fine. Existing users of the interface
in tree (libxl, ocaml and python bindings) are currently using signed int
for pirq representation which should be wide enough. Converting them to
uint32_t now is desirable to avoid accidental passing of a negative
number (probably denoting an error code) by caller as pirq, but left for
the future clean up.

Domctl interface version is needed to be bumped with this change but that
was already done by 918b8842a8 ("arm64: Change type of hsr, cpsr, spsr_el1
to uint64_t") in this release cycle.

Additionally, take a change and convert allow_access argument to bool.

Reviewed-by: Jan Beulich 
Signed-off-by: Igor Druzhinin 
Acked-by: Christian Lindig 
---

Changes in v2:
- extra wording for clarity in commit message (Julien)
- change allow_access to bool (Andrew)
- add padding (Jan)

---
 tools/include/xenctrl.h | 4 ++--
 tools/libs/ctrl/xc_domain.c | 4 ++--
 tools/ocaml/libs/xc/xenctrl_stubs.c | 4 ++--
 xen/include/public/domctl.h | 3 ++-
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 2a7c836..14adaa0 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1385,8 +1385,8 @@ int xc_domain_ioport_permission(xc_interface *xch,
 
 int xc_domain_irq_permission(xc_interface *xch,
  uint32_t domid,
- uint8_t pirq,
- uint8_t allow_access);
+ uint32_t pirq,
+ bool allow_access);
 
 int xc_domain_iomem_permission(xc_interface *xch,
uint32_t domid,
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index 7d11884..1cdf3d1 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -1384,8 +1384,8 @@ int xc_vcpu_setcontext(xc_interface *xch,
 
 int xc_domain_irq_permission(xc_interface *xch,
  uint32_t domid,
- uint8_t pirq,
- uint8_t allow_access)
+ uint32_t pirq,
+ bool allow_access)
 {
 DECLARE_DOMCTL;
 
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index 6e4bc56..266eb32 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -1077,8 +1077,8 @@ CAMLprim value stub_xc_domain_irq_permission(value xch, 
value domid,
 value pirq, value allow)
 {
CAMLparam4(xch, domid, pirq, allow);
-   uint8_t c_pirq;
-   uint8_t c_allow;
+   uint32_t c_pirq;
+   bool c_allow;
int ret;
 
c_pirq = Int_val(pirq);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 4dbf107..088c964 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -441,8 +441,9 @@ struct xen_domctl_setdebugging {
 
 /* XEN_DOMCTL_irq_permission */
 struct xen_domctl_irq_permission {
-uint8_t pirq;
+uint32_t pirq;
 uint8_t allow_access;/* flag to specify enable/disable of IRQ access */
+uint8_t pad[3];
 };
 
 
-- 
2.7.4

[ovmf test] 163612: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 
162359

version targeted for testing:
 ovmf fb5b6220a9718fc28ae67f317d3611214a05589c
baseline version:
 ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb

Last test of basis   162359  2021-06-04 03:40:08 Z   38 days
Failing since162368  2021-06-04 15:42:59 Z   38 days  108 attempts
Testing same since   163612  2021-07-12 17:41:17 Z0 days1 attempts


People who touched revisions under test:
  Abner Chang 
  Agrawal, Sachin 
  Alexandru Elisei 
  Anthony PERARD 
  Ard Biesheuvel 
  Ashraf Ali S 
  Bob Feng 
  Bret Barkelew 
  Chen, Christine 
  Corvin Köhne 
  Daniel Schaefer 
  Daoxiang Li 
  Dov Murik 
  DunTan 
  gaoliming 
  Guo Dong 
  Hao A Wu 
  Jian J Wang 
  Jianyong Wu 
  Kaaira Gupta 
  Ken Lautner 
  Kenneth Lautner 
  Kun Qin 
  Laszlo Ersek 
  Leif Lindholm 
  Liming Gao 
  Loo Tung Lun 
  Loo, Tung Lun 
  Manickavasakam Karpagavinayagam 
  Maurice Ma 
  Michael D Kinney 
  Neal Gompa 
  Ni, Ray 
  Nickle Wang 
  Patrick Rudolph 
  Pierre Gondois 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  S, Ashraf Ali 
  Sachin Agrawal 
  Sami Mujawar 
  Scottie Kuo 
  Sean Brogan 
  Sean Brogan 
  Sheng Wei 
  Sumana Venur 
  Sunil V L 
  xueshengfeng 
  Yuwei Chen 
  Zhiguang Liu 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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


Not pushing.

(No revision log; it would be 3703 lines long.)

[PATCH 0/4] Remove unconditional arch dependency on asm/debugger.h

[Bobby Eshleman]

Currently, any architecture wishing to use common/ is likely
to be required to implement the functions found in "asm/debugger.h".
Some architectures, however, do not have an actual use for these
functions and so are forced to implement stubs.  This patch does the
following:

* Supplies common stubs if !CONFIG_CRASH_DEBUG for any architecture,
  removing the need for all new architectures to have "asm/debugger.h".
* Moves the x86 implementation to "arch/x86/debugger.c".
* Removes the ARM calls to its stubs.
* Centralizes x86 code conditionally compiled by CONFIG_CRASH_DEBUG
  into arch/x86/debugger.c, which is now conditionally built for
  CONFIG_CRASH_DEBUG via Kbuild (i.e., obj-$(CONFIG_CRASH_DEBUG)).
* Tries to improve the x86 implementation by not inlining large
  functions (but preserving inlining for those that seemed "small").

Bobby Eshleman (4):
  build: use common stubs for debugger_trap_* functions if
!CONFIG_CRASH_DEBUG
  arm/traps: remove debugger_trap_fatal() calls
  x86/debug: move debugger_trap_entry into debugger.c not inlined
  x86/debug: move domain_pause_for_debugger to debugger.c

 xen/arch/arm/traps.c|  8 +--
 xen/arch/x86/Makefile   |  1 +
 xen/arch/x86/debug.c|  2 +-
 xen/arch/x86/debugger.c | 53 
 xen/arch/x86/domain.c   | 15 +-
 xen/arch/x86/domctl.c   |  2 +-
 xen/arch/x86/gdbstub.c  |  4 +-
 xen/arch/x86/hvm/svm/svm.c  |  2 +-
 xen/arch/x86/hvm/vmx/realmode.c |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c  |  2 +-
 xen/arch/x86/nmi.c  |  2 +-
 xen/arch/x86/traps.c|  2 +-
 xen/arch/x86/x86_64/gdbstub.c   |  3 +-
 xen/common/domain.c |  2 +-
 xen/common/gdbstub.c|  3 +-
 xen/common/keyhandler.c |  2 +-
 xen/common/shutdown.c   |  2 +-
 xen/drivers/char/console.c  |  2 +-
 xen/include/asm-arm/debugger.h  | 15 --
 xen/include/asm-x86/debugger.h  | 89 -
 xen/include/xen/debugger.h  | 81 ++
 21 files changed, 166 insertions(+), 128 deletions(-)
 create mode 100644 xen/arch/x86/debugger.c
 delete mode 100644 xen/include/asm-arm/debugger.h
 create mode 100644 xen/include/xen/debugger.h

-- 
2.30.0

[PATCH 1/4] build: use common stubs for debugger_trap_* functions if !CONFIG_CRASH_DEBUG

[Bobby Eshleman]

Previously Xen required all architectures implement the debugger_trap_*
functions whether or not it actually needs them.

This commit makes debugger_trap* functions resolve to arch-specific
function definitions if CONFIG_CRASH_DEBUG=y, but resolves to a set of
common no-op stubs if !CONFIG_CRASH_DEBUG, which avoids requiring every
arch to carry its own stubs.  This means asm/debugger.h may also be
dropped for architectures that do not need this functionality.

Inside xen/debugger.h:
* If !CONFIG_CRASH_DEBUG, use stubs.
* Otherwise, include arch-specific 

Signed-off-by: Bobby Eshleman 
---
 xen/arch/arm/traps.c|  2 +-
 xen/arch/x86/debug.c|  2 +-
 xen/arch/x86/domain.c   |  5 +-
 xen/arch/x86/domctl.c   |  2 +-
 xen/arch/x86/gdbstub.c  |  4 +-
 xen/arch/x86/hvm/svm/svm.c  |  2 +-
 xen/arch/x86/hvm/vmx/realmode.c |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c  |  2 +-
 xen/arch/x86/nmi.c  |  2 +-
 xen/arch/x86/traps.c|  2 +-
 xen/arch/x86/x86_64/gdbstub.c   |  3 +-
 xen/common/domain.c |  2 +-
 xen/common/gdbstub.c|  3 +-
 xen/common/keyhandler.c |  2 +-
 xen/common/shutdown.c   |  2 +-
 xen/drivers/char/console.c  |  2 +-
 xen/include/asm-arm/debugger.h  | 15 --
 xen/include/asm-x86/debugger.h  | 66 +--
 xen/include/xen/debugger.h  | 81 +
 19 files changed, 115 insertions(+), 86 deletions(-)
 delete mode 100644 xen/include/asm-arm/debugger.h
 create mode 100644 xen/include/xen/debugger.h

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4ccb6e7d18..5a0a5eff1d 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -41,7 +41,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index d90dc93056..4386e8d1b1 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 typedef unsigned long dbgva_t;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ef1812dc14..47448f2f8c 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2539,9 +2540,9 @@ static int __init init_vcpu_kick_softirq(void)
 }
 __initcall(init_vcpu_kick_softirq);
 
+#ifdef CONFIG_CRASH_DEBUG
 void domain_pause_for_debugger(void)
 {
-#ifdef CONFIG_CRASH_DEBUG
 struct vcpu *curr = current;
 struct domain *d = curr->domain;
 
@@ -2550,8 +2551,8 @@ void domain_pause_for_debugger(void)
 /* if gdbsx active, we just need to pause the domain */
 if ( curr->arch.gdbsx_vcpu_event == 0 )
 send_global_virq(VIRQ_DEBUGGER);
-#endif
 }
+#endif
 
 /*
  * Local variables:
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 26a76d2be9..1bc8ba7251 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/gdbstub.c b/xen/arch/x86/gdbstub.c
index 8f4f49fd3b..f20cbf1f45 100644
--- a/xen/arch/x86/gdbstub.c
+++ b/xen/arch/x86/gdbstub.c
@@ -18,7 +18,9 @@
  * You should have received a copy of the GNU General Public License
  * along with this program; If not, see .
  */
-#include 
+#include 
+#include 
+#include 
 
 u16
 gdb_arch_signal_num(struct cpu_user_regs *regs, unsigned long cookie)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 642a64b747..d7ec7c15f9 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -58,7 +58,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vmx/realmode.c b/xen/arch/x86/hvm/vmx/realmode.c
index cc23afa788..1f8513c132 100644
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e09b7e3af9..1820e4be0c 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -51,7 +51,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index ab94a96c4d..eaf404402d 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index e60af16ddd..44811c9599 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -62,7 +62,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/x86_64/gdbstub.c b/xen/arch/x86/x86_64/gdbstub.c

[PATCH 2/4] arm/traps: remove debugger_trap_fatal() calls

[Bobby Eshleman]

ARM doesn't actually use debugger_trap_* anything, and is stubbed out.

Simply remove the calls. This also renders TRAP_invalid_op unused in
any common code, so remove that definition too.

Signed-off-by: Bobby Eshleman 
---
 xen/arch/arm/traps.c   | 6 --
 xen/include/xen/debugger.h | 5 -
 2 files changed, 11 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5a0a5eff1d..0310bc91a0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1266,10 +1266,6 @@ int do_bug_frame(const struct cpu_user_regs *regs, 
vaddr_t pc)
 
 case BUGFRAME_bug:
 printk("Xen BUG at %s%s:%d\n", prefix, filename, lineno);
-
-if ( debugger_trap_fatal(TRAP_invalid_op, regs) )
-return 0;
-
 show_execution_state(regs);
 panic("Xen BUG at %s%s:%d\n", prefix, filename, lineno);
 
@@ -1281,8 +1277,6 @@ int do_bug_frame(const struct cpu_user_regs *regs, 
vaddr_t pc)
 
 printk("Assertion '%s' failed at %s%s:%d\n",
predicate, prefix, filename, lineno);
-if ( debugger_trap_fatal(TRAP_invalid_op, regs) )
-return 0;
 show_execution_state(regs);
 panic("Assertion '%s' failed at %s%s:%d\n",
   predicate, prefix, filename, lineno);
diff --git a/xen/include/xen/debugger.h b/xen/include/xen/debugger.h
index d6d820f4e5..8297e582e4 100644
--- a/xen/include/xen/debugger.h
+++ b/xen/include/xen/debugger.h
@@ -36,11 +36,6 @@
 #ifndef __XEN_DEBUGGER_H__
 #define __XEN_DEBUGGER_H__
 
-/* Dummy value used by ARM stubs. */
-#ifndef TRAP_invalid_op
-# define TRAP_invalid_op 6
-#endif
-
 #ifdef CONFIG_CRASH_DEBUG
 
 #include 
-- 
2.30.0

[PATCH 3/4] x86/debug: move debugger_trap_entry into debugger.c not inlined

[Bobby Eshleman]

The function debugger_trap_entry() is rather large for an inlined
function.  This commit moves debugger_trap_entry() into debugger.c and
makes it not inlined.

Signed-off-by: Bobby Eshleman 
---
 xen/arch/x86/Makefile  |  1 +
 xen/arch/x86/debugger.c| 41 ++
 xen/include/asm-x86/debugger.h | 29 ++--
 3 files changed, 44 insertions(+), 27 deletions(-)
 create mode 100644 xen/arch/x86/debugger.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 2ec883456e..ba274fb8e6 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -32,6 +32,7 @@ obj-y += emul-i8254.o
 obj-y += extable.o
 obj-y += flushtlb.o
 obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
+obj-$(CONFIG_CRASH_DEBUG) += debugger.o
 obj-y += hypercall.o
 obj-y += i387.o
 obj-y += i8259.o
diff --git a/xen/arch/x86/debugger.c b/xen/arch/x86/debugger.c
new file mode 100644
index 00..6f33f509ff
--- /dev/null
+++ b/xen/arch/x86/debugger.c
@@ -0,0 +1,41 @@
+/**
+ * x86 crash debug hooks
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+bool debugger_trap_entry(
+unsigned int vector, struct cpu_user_regs *regs)
+{
+/*
+ * This function is called before any checks are made.  Amongst other
+ * things, be aware that during early boot, current is not a safe pointer
+ * to follow.
+ */
+struct vcpu *v = current;
+
+if ( vector != TRAP_int3 && vector != TRAP_debug )
+return false;
+
+if ( guest_mode(regs) && guest_kernel_mode(v, regs) &&
+ v->domain->debugger_attached  )
+{
+if ( vector != TRAP_debug ) /* domain pause is good enough */
+current->arch.gdbsx_vcpu_event = vector;
+domain_pause_for_debugger();
+return true;
+}
+
+return false;
+}
diff --git a/xen/include/asm-x86/debugger.h b/xen/include/asm-x86/debugger.h
index 38359da0a1..0e30d27a4e 100644
--- a/xen/include/asm-x86/debugger.h
+++ b/xen/include/asm-x86/debugger.h
@@ -15,9 +15,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 void domain_pause_for_debugger(void);
 
@@ -31,29 +28,7 @@ static inline bool debugger_trap_fatal(
 /* Int3 is a trivial way to gather cpu_user_regs context. */
 #define debugger_trap_immediate() __asm__ __volatile__ ( "int3" );
 
-static inline bool debugger_trap_entry(
-unsigned int vector, struct cpu_user_regs *regs)
-{
-/*
- * This function is called before any checks are made.  Amongst other
- * things, be aware that during early boot, current is not a safe pointer
- * to follow.
- */
-struct vcpu *v = current;
-
-if ( vector != TRAP_int3 && vector != TRAP_debug )
-return false;
-
-if ( guest_mode(regs) && guest_kernel_mode(v, regs) &&
- v->domain->debugger_attached  )
-{
-if ( vector != TRAP_debug ) /* domain pause is good enough */
-current->arch.gdbsx_vcpu_event = vector;
-domain_pause_for_debugger();
-return true;
-}
-
-return false;
-}
+bool debugger_trap_entry(
+unsigned int vector, struct cpu_user_regs *regs);
 
 #endif /* __X86_DEBUGGER_H__ */
-- 
2.30.0

[PATCH 4/4] x86/debug: move domain_pause_for_debugger to debugger.c

[Bobby Eshleman]

The function domain_pause_for_debugger() is conditionally compiled if
CONFIG_CRASH_DEBUG=y.  Instead of placing an extra #ifdef inside
domain.c, this commit moves domain_pause_for_debugger() into
x86/debugger.c which is only built by Kbuild given CONFIG_CRASH_DEBUG=y.

Signed-off-by: Bobby Eshleman 
---
 xen/arch/x86/debugger.c | 12 
 xen/arch/x86/domain.c   | 14 --
 2 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/debugger.c b/xen/arch/x86/debugger.c
index 6f33f509ff..4f7c44600f 100644
--- a/xen/arch/x86/debugger.c
+++ b/xen/arch/x86/debugger.c
@@ -15,6 +15,18 @@
 #include 
 #include 
 
+void domain_pause_for_debugger(void)
+{
+struct vcpu *curr = current;
+struct domain *d = curr->domain;
+
+domain_pause_by_systemcontroller_nosync(d);
+
+/* if gdbsx active, we just need to pause the domain */
+if ( curr->arch.gdbsx_vcpu_event == 0 )
+send_global_virq(VIRQ_DEBUGGER);
+}
+
 bool debugger_trap_entry(
 unsigned int vector, struct cpu_user_regs *regs)
 {
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 47448f2f8c..545da32c3b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2540,20 +2540,6 @@ static int __init init_vcpu_kick_softirq(void)
 }
 __initcall(init_vcpu_kick_softirq);
 
-#ifdef CONFIG_CRASH_DEBUG
-void domain_pause_for_debugger(void)
-{
-struct vcpu *curr = current;
-struct domain *d = curr->domain;
-
-domain_pause_by_systemcontroller_nosync(d);
-
-/* if gdbsx active, we just need to pause the domain */
-if ( curr->arch.gdbsx_vcpu_event == 0 )
-send_global_virq(VIRQ_DEBUGGER);
-}
-#endif
-
 /*
  * Local variables:
  * mode: C
-- 
2.30.0

[PATCH] vl: Parse legacy default_machine_opts

[Jason Andryuk]

qemu can't start a xen vm after commit d8fb7d0969d5
"vl: switch -M parsing to keyval" with:

$ ./qemu-system-i386 -M xenfv
Unexpected error in object_property_find_err() at ../qom/object.c:1298:
qemu-system-i386: Property 'xenfv-3.1-machine.accel' not found
Aborted (core dumped)

The default_machine_opts handling doesn't process the legacy machine
options like "accel".  Call qemu_apply_legacy_machine_options to provide
the legacy handling.

Signed-off-by: Jason Andryuk 
---
 softmmu/vl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/softmmu/vl.c b/softmmu/vl.c
index 4df1496101..f4d8630fc6 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2126,6 +2126,7 @@ static void qemu_create_machine(QDict *qdict)
 QDict *default_opts =
 keyval_parse(machine_class->default_machine_opts, NULL, NULL,
  &error_abort);
+qemu_apply_legacy_machine_options(default_opts);
 object_set_properties_from_keyval(OBJECT(current_machine), 
default_opts,
   false, &error_abort);
 qobject_unref(default_opts);
-- 
2.30.2

[xen-unstable-smoke test] 163619: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 163474

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  93c9edbef51b31056f93a37a778326c90a83158c
baseline version:
 xen  6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf

Last test of basis   163474  2021-07-09 12:00:25 Z3 days
Failing since163480  2021-07-09 16:08:01 Z3 days   20 attempts
Testing same since   163489  2021-07-09 21:00:27 Z3 days   19 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Costin Lupu 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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
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


Not pushing.


commit 93c9edbef51b31056f93a37a778326c90a83158c
Author: Andrew Cooper 
Date:   Tue Jun 15 16:02:29 2021 +0100

tests/xenstore: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

This causes the code to be noticed by CI, which objects as follows:

  test-xenstore.c: In function 'main':
  test-xenstore.c:486:5: error: ignoring return value of 'asprintf', 
declared
  with attribute warn_unused_result [-Werror=unused-result]
   asprintf(&path, "%s/%u", TEST_PATH, getpid());
   ^

Address the CI failure by checking the asprintf() return value and exiting.

Rename xs-test to test-xenstore to be consistent with other tests.  Honour
APPEND_FLAGS too.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 6a9f5477637a9f2d1d61c0a065eeb01bf84f6484
Author: Andrew Cooper 
Date:   Tue Jun 15 15:37:49 2021 +0100

tests/cpu-policy: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Rework TARGET-y to be TARGETS, drop redundant -f's for $(RM), drop the
unconditional -O3 and use the default instead, and drop CFLAGS from the link
line but honour APPEND_LDFLAGS.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit ff759953b32286f376fda7f3ff5a17eccb542b03
Author: Andrew Cooper 
Date:   Tue Jun 15 15:22:11 2021 +0100

tests/resource: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Make all object files depend on the Makefile, drop redundant -f's for $(RM),
and use $(TARGET) when appropriate.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 79ca512a1fa68e0170a85cb71b8a8e8f4a34fb11
Author: Andrew Cooper 
Date:   Tue Jun 15 14:19:15 2021 +0100

tools/tests: Drop obsolete mce-test infrastructure

mce-test has a test suite, but it depends on xend, needs to run in-tree, and
requires manual setup of at least one guest, and manual parameters to pass
into cases.  Drop th

DMA restriction and NUMA node number

[Wei Chen]

Hi,

I am doing some NUMA testing on Xen. And I find the DMA restriction is
based on NUMA node number [1].
if ( !dma_bitsize && (num_online_nodes() > 1) )
dma_bitsize = arch_get_dma_bitsize();

On Arm64, we will set dma_bitsize [2] to 0, that means we don't need to
reserve DMA memory. But when num_online_nodes > 1, the dma_bitsize
will override to 32. This may be caused by the Arm64 version
arch_get_dma_bitsize, it may be a simple implementation and not NUMA
aware.

But I still quite curious about why DMA restriction depends on NUMA
node number. In Arm64, dma_bitsize does not change when the NUMA node
changes. So we didn't expect arch_get_dma_bitsize to be called here.

I copied Keir's commit message from 2008. It seems this code was considered
only for x86, when he was working on it. But I'm not an x86 expert, so I
hope Xen x86 folks can give some help. Understanding this will help us to
do some adaptations to Arm in subsequent modifications : )

commit accacb43cb7f16e9d1d8c0e58ea72c9d0c32cec2
Author: Keir Fraser 
Date:   Mon Jul 28 16:40:30 2008 +0100

Simplify 'dma heap' logic.

1. Only useful for NUMA systems, so turn it off on non-NUMA systems by
   default.
2. On NUMA systems, by default relate the DMA heap size to NUMA node 0
   memory size (so that not all of node 0's memory ends up being 'DMA
   heap').
3. Remove the 'dma emergency pool'. It's less useful now that running
   out of low memory isn;t as fatal as it used to be (e.g., when we
   needed to be able to allocate low-memory PAE page directories).

[1] 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/page_alloc.c;h=958ba0cd9256c8270e38585d272be2bf5cc0679e;hb=refs/heads/master#l1876
[2] 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/page_alloc.c;h=958ba0cd9256c8270e38585d272be2bf5cc0679e;hb=refs/heads/master#l226


--
Cheers,
Wei Chen

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[xen-unstable test] 163610: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-amd 16 xen-boot/l1 fail REGR. vs. 163458

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 163458
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 163458
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 163458
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 163458
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 163458
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 163458
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 163458
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 163458
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 163458
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 163458
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass

version targeted for testing:
 xen  6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf
baseline version:
 xen  0f435e2b58543f5baae96e17a10ae20d3dbc28fa

Last test of basis   163458  2021-07-08 23:09:08 Z4 days
Testing same since   163478  2021-07-09 15:23:45 Z3 days7 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christopher Clark 
  Daniel P. Smith 
  Jan Beulich 
  Olaf Hering 
  Richard Kojedzinszky 
  Roger Pau

[xen-unstable-smoke test] 163627: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 163474

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  93c9edbef51b31056f93a37a778326c90a83158c
baseline version:
 xen  6de3e5fce5e2a3c5f438e8e214168dd3a474cbbf

Last test of basis   163474  2021-07-09 12:00:25 Z3 days
Failing since163480  2021-07-09 16:08:01 Z3 days   21 attempts
Testing same since   163489  2021-07-09 21:00:27 Z3 days   20 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Costin Lupu 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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
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


Not pushing.


commit 93c9edbef51b31056f93a37a778326c90a83158c
Author: Andrew Cooper 
Date:   Tue Jun 15 16:02:29 2021 +0100

tests/xenstore: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

This causes the code to be noticed by CI, which objects as follows:

  test-xenstore.c: In function 'main':
  test-xenstore.c:486:5: error: ignoring return value of 'asprintf', 
declared
  with attribute warn_unused_result [-Werror=unused-result]
   asprintf(&path, "%s/%u", TEST_PATH, getpid());
   ^

Address the CI failure by checking the asprintf() return value and exiting.

Rename xs-test to test-xenstore to be consistent with other tests.  Honour
APPEND_FLAGS too.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 6a9f5477637a9f2d1d61c0a065eeb01bf84f6484
Author: Andrew Cooper 
Date:   Tue Jun 15 15:37:49 2021 +0100

tests/cpu-policy: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Rework TARGET-y to be TARGETS, drop redundant -f's for $(RM), drop the
unconditional -O3 and use the default instead, and drop CFLAGS from the link
line but honour APPEND_LDFLAGS.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit ff759953b32286f376fda7f3ff5a17eccb542b03
Author: Andrew Cooper 
Date:   Tue Jun 15 15:22:11 2021 +0100

tests/resource: Rework Makefile

In particular, fill in the install/uninstall rules so this test can be
packaged to be automated sensibly.

Make all object files depend on the Makefile, drop redundant -f's for $(RM),
and use $(TARGET) when appropriate.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 79ca512a1fa68e0170a85cb71b8a8e8f4a34fb11
Author: Andrew Cooper 
Date:   Tue Jun 15 14:19:15 2021 +0100

tools/tests: Drop obsolete mce-test infrastructure

mce-test has a test suite, but it depends on xend, needs to run in-tree, and
requires manual setup of at least one guest, and manual parameters to pass
into cases.  Drop th

Re: [PATCH v2 01/10] xen: Implement xen/alternative-call.h for use in common code

[Jan Beulich]

On 13.07.2021 01:48, Andrew Cooper wrote:
> On 12/07/2021 21:32, Daniel P. Smith wrote:
>> diff --git a/xen/include/xen/alternative-call.h 
>> b/xen/include/xen/alternative-call.h
>> new file mode 100644
>> index 00..11d1c26068
>> --- /dev/null
>> +++ b/xen/include/xen/alternative-call.h
>> @@ -0,0 +1,65 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef XEN_ALTERNATIVE_CALL
>> +#define XEN_ALTERNATIVE_CALL
>> +
>> +/*
>> + * Some subsystems in Xen may have multiple implementions, which can be
>> + * resolved to a single implementation at boot time.  By default, this will
>> + * result in the use of function pointers.
>> + *
>> + * Some architectures may have mechanisms for dynamically modifying .text.
>> + * Using this mechnaism, function pointers can be converted to direct calls
>> + * which are typically more efficient at runtime.
>> + *
>> + * For architectures to support:
>> + *
>> + * - Implement alternative_{,v}call() in asm/alternative.h.  Code generation
>> + *   requirements are to emit a function pointer call at build time, and 
>> stash
>> + *   enough metadata to simplify the call at boot once the implementation 
>> has
>> + *   been resolved.
>> + * - Select ALTERNATIVE_CALL in Kconfig.
>> + *
>> + * To use:
>> + *
>> + * Consider the following simplified example.
>> + *
>> + *  1) struct foo_ops __alt_call_maybe_initdata ops;
>> + *
>> + *  2) struct foo_ops __alt_call_maybe_initconst foo_a_ops = { ... };
>> + * struct foo_ops __alt_call_maybe_initconst foo_b_ops = { ... };
> 
> It occurs to me after reviewing patch 2 that these want to be const
> struct foo_ops __initconst ...,

__initconstrel then, I suppose.

> and there is no need for
> __alt_call_maybe_initconst at all.
> 
> The only thing wanting a conditional annotation like this is the single
> ops object, and it needs to be initdata (or hopefully ro_after_init in
> the future).

ro_after_init and initdata can't be alternatives of one another; ops
(until be gain ro_after_init) need to remain in .bss (or .data).

Jan

Re: [PATCH v4 3/5] tools/libs/foreignmemory: Fix PAGE_SIZE redefinition error

[Jan Beulich]

On 08.06.2021 14:35, Costin Lupu wrote:
> --- a/tools/libs/foreignmemory/private.h
> +++ b/tools/libs/foreignmemory/private.h
> @@ -1,6 +1,7 @@
>  #ifndef XENFOREIGNMEMORY_PRIVATE_H
>  #define XENFOREIGNMEMORY_PRIVATE_H
>  
> +#include 
>  #include 
>  
>  #include 

At the risk of repeating what may have been discussed on irc already yesterday
(which I would not have seen), this is the cause for the present smoke test
failure:

In file included from 
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:39,
 from 
/home/osstest/build.163627.build-amd64/xen/tools/include/xenctrl.h:36,
 from private.h:4,
 from minios.c:29:
/home/osstest/build.163627.build-amd64/xen/xen/include/public/memory.h:407:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(const_uint8) buffer;
 ^~~
In file included from 
/home/osstest/build.163627.build-amd64/xen/tools/include/xenctrl.h:36,
 from private.h:4,
 from minios.c:29:
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:101:34: 
error: field 'arch' has incomplete type
 struct xen_arch_domainconfig arch;
  ^~~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:152:34: 
error: field 'arch_config' has incomplete type
 struct xen_arch_domainconfig arch_config;
  ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:182:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(xen_pfn_t) array;
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:263:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(uint8) dirty_bitmap;
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:280:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(vcpu_guest_context_t) ctxt; /* IN/OUT */
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:301:26: 
error: field 'nodemap' has incomplete type
 struct xenctl_bitmap nodemap;/* IN */
  ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:337:26: 
error: field 'cpumap_hard' has incomplete type
 struct xenctl_bitmap cpumap_hard;
  ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:338:26: 
error: field 'cpumap_soft' has incomplete type
 struct xenctl_bitmap cpumap_soft;
  ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:418:13: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(xen_domctl_schedparam_vcpu_t) vcpus;
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:473:5: 
error: unknown type name 'int64_aligned_t'
 int64_aligned_t time_offset_seconds; /* applied to domain wallclock time */
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:480:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(uint8) buffer; /* IN/OUT: data, or call
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:533:13: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(char) path; /* path to the device tree node */
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:544:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(uint32)  sdev_array;   /* OUT */
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:685:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(xen_cpuid_leaf_t) cpuid_policy; /* IN/OUT */
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:735:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(uint8) buffer;  /* OUT: buffer to write record into */
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:909:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(uint64) buffer;
 ^~~
/home/osstest/build.163627.build-amd64/xen/stubdom/include/xen/domctl.h:963:5: 
error: expected specifier-qualifier-list before 'XEN_GUEST_HANDLE_64'
 XEN_GUEST_HANDLE_64(xen_domctl_vcpu_msr_t) msrs; /* IN/OUT */
 ^~~
/home/osstest/build.163627.build-