Re: [PATCH v7 0/7] xl / libxl: named PCI pass-through devices

[Oleksandr Andrushchenko]

Hi, Wei!

Is this series good to go? Could you please tell if it breaks anything?

Thank you in advance,

Oleksandr

On 1/5/21 7:46 PM, Paul Durrant wrote:
> From: Paul Durrant 
>
> These are re-worked versions of the remaining patches from v6 of the series
> that were reverted by commit ac6a0af3870b "Revert patches that break libxl
> API".
>
> Paul Durrant (7):
>docs/man: modify xl(1) in preparation for naming of assignable devices
>libxlu: introduce xlu_pci_parse_spec_string()
>libxl: stop setting 'vdevfn' in pci_struct_fill()
>libxl: add 'name' field to 'libxl_device_pci' in the IDL...
>xl: support naming of assignable devices
>docs/man: modify xl-pci-configuration(5) to add 'name' field to
>  PCI_SPEC_STRING
>libxl / libxlu: support 'xl pci-attach/detach' by name
>
>   docs/man/xl-pci-configuration.5.pod |  25 ++-
>   docs/man/xl.1.pod.in|  19 +-
>   tools/include/libxl.h   |   6 +
>   tools/include/libxlutil.h   |   8 +-
>   tools/libs/light/libxl_pci.c| 133 --
>   tools/libs/light/libxl_types.idl|  13 +-
>   tools/libs/util/libxlu_pci.c| 353 
> +++-
>   tools/xl/xl_cmdtable.c  |  16 +-
>   tools/xl/xl_parse.c |   4 +-
>   tools/xl/xl_pci.c   | 120 
>   10 files changed, 457 insertions(+), 240 deletions(-)
>

Re: [PATCH v2] xen/arm: don't read aarch32 regs when aarch32 isn't available

[Bertrand Marquis]

Hi Stefano,

> On 12 Jan 2021, at 23:44, Stefano Stabellini  wrote:
> 
> Don't read aarch32 system registers at boot time when the aarch32 state
> is not available at EL0. They are UNKNOWN, so it is not useful to read
> them.  Moreover, on Cavium ThunderX reading ID_PFR2_EL1 causes a Xen
> crash.  Instead, only read them when aarch32 is available.

Might be a good idea to say that on Cavium ID_PFR2_EL1 is generating an
unsupported exception causing a Xen crash on boot.

> 
> Leave the corresponding fields in struct cpuinfo_arm so that they
> are read-as-zero from a guest.
> 
> Since we are editing identify_cpu, also fix the indentation: 4 spaces
> instead of 8.
> 
> Fixes: 9cfdb489af81 ("xen/arm: Add ID registers and complete cpuinfo")
> Link: 
> https://lore.kernel.org/xen-devel/f90e40ee-b042-6cc5-a08d-aef41a279...@suse.com/
> Suggested-by: Julien Grall 
> Signed-off-by: Stefano Stabellini 
with this added:

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> Changes in v2:
> - check el0 instead of el1 for aarch32 support
> - clarify EL0 in commit message
> - remove temporary link in commit message
> - use lore.kernel.org in commit message
> - introduce cpu_feature64_has_el0_32
> - rename aarch32 to aarch32_el0
> ---
> xen/arch/arm/cpufeature.c| 35 +++-
> xen/include/asm-arm/cpufeature.h |  2 ++
> 2 files changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 698bfa0201..99fe4db280 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -101,29 +101,35 @@ int enable_nonboot_cpu_caps(const struct 
> arm_cpu_capabilities *caps)
> 
> void identify_cpu(struct cpuinfo_arm *c)
> {
> -c->midr.bits = READ_SYSREG(MIDR_EL1);
> -c->mpidr.bits = READ_SYSREG(MPIDR_EL1);
> +bool aarch32_el0 = true;
> +
> +c->midr.bits = READ_SYSREG(MIDR_EL1);
> +c->mpidr.bits = READ_SYSREG(MPIDR_EL1);
> 
> #ifdef CONFIG_ARM_64
> -c->pfr64.bits[0] = READ_SYSREG(ID_AA64PFR0_EL1);
> -c->pfr64.bits[1] = READ_SYSREG(ID_AA64PFR1_EL1);
> +c->pfr64.bits[0] = READ_SYSREG(ID_AA64PFR0_EL1);
> +c->pfr64.bits[1] = READ_SYSREG(ID_AA64PFR1_EL1);
> +
> +c->dbg64.bits[0] = READ_SYSREG(ID_AA64DFR0_EL1);
> +c->dbg64.bits[1] = READ_SYSREG(ID_AA64DFR1_EL1);
> 
> -c->dbg64.bits[0] = READ_SYSREG(ID_AA64DFR0_EL1);
> -c->dbg64.bits[1] = READ_SYSREG(ID_AA64DFR1_EL1);
> +c->aux64.bits[0] = READ_SYSREG(ID_AA64AFR0_EL1);
> +c->aux64.bits[1] = READ_SYSREG(ID_AA64AFR1_EL1);
> 
> -c->aux64.bits[0] = READ_SYSREG(ID_AA64AFR0_EL1);
> -c->aux64.bits[1] = READ_SYSREG(ID_AA64AFR1_EL1);
> +c->mm64.bits[0]  = READ_SYSREG(ID_AA64MMFR0_EL1);
> +c->mm64.bits[1]  = READ_SYSREG(ID_AA64MMFR1_EL1);
> +c->mm64.bits[2]  = READ_SYSREG(ID_AA64MMFR2_EL1);
> 
> -c->mm64.bits[0]  = READ_SYSREG(ID_AA64MMFR0_EL1);
> -c->mm64.bits[1]  = READ_SYSREG(ID_AA64MMFR1_EL1);
> -c->mm64.bits[2]  = READ_SYSREG(ID_AA64MMFR2_EL1);
> +c->isa64.bits[0] = READ_SYSREG(ID_AA64ISAR0_EL1);
> +c->isa64.bits[1] = READ_SYSREG(ID_AA64ISAR1_EL1);
> 
> -c->isa64.bits[0] = READ_SYSREG(ID_AA64ISAR0_EL1);
> -c->isa64.bits[1] = READ_SYSREG(ID_AA64ISAR1_EL1);
> +c->zfr64.bits[0] = READ_SYSREG(ID_AA64ZFR0_EL1);
> 
> -c->zfr64.bits[0] = READ_SYSREG(ID_AA64ZFR0_EL1);
> +aarch32_el0 = cpu_feature64_has_el0_32(c);
> #endif
> 
> +if ( aarch32_el0 )
> +{
> c->pfr32.bits[0] = READ_SYSREG(ID_PFR0_EL1);
> c->pfr32.bits[1] = READ_SYSREG(ID_PFR1_EL1);
> c->pfr32.bits[2] = READ_SYSREG(ID_PFR2_EL1);
> @@ -153,6 +159,7 @@ void identify_cpu(struct cpuinfo_arm *c)
> #ifndef MVFR2_MAYBE_UNDEFINED
> c->mvfr.bits[2] = READ_SYSREG(MVFR2_EL1);
> #endif
> +}
> }
> 
> /*
> diff --git a/xen/include/asm-arm/cpufeature.h 
> b/xen/include/asm-arm/cpufeature.h
> index 6058744c18..13a2739a69 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -5,6 +5,8 @@
> #define cpu_feature64(c, feat) ((c)->pfr64.feat)
> #define boot_cpu_feature64(feat)   (boot_cpu_data.pfr64.feat)
> 
> +#define cpu_feature64_has_el0_32(c)(cpu_feature64(c, el0) == 2)
> +
> #define cpu_has_el0_32(boot_cpu_feature64(el0) == 2)
> #define cpu_has_el0_64(boot_cpu_feature64(el0) >= 1)
> #define cpu_has_el1_32(boot_cpu_feature64(el1) == 2)
> -- 
> 2.17.1
> 

[libvirt test] 158397: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-armhf-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  97b1de50512dc24e1ee118af2ee148f652875bf8
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  187 days
Failing since151818  2020-07-11 04:18:52 Z  186 days  181 attempts
Testing same since   158397  2021-01-13 04:19:20 Z0 days1 attempts


People who touched revisions under test:
  Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Andika Triwidada 
  Andrea Bolognani 
  Balázs Meskó 
  Barrett Schonefeld 
  Bastien Orivel 
  Bihong Yu 
  Binfeng Wu 
  Boris Fiuczynski 
  Brian Turek 
  Christian Ehrhardt 
  Christian Schoenebeck 
  Cole Robinson 
  Collin Walling 
  Cornelia Huck 
  Côme Borsoi 
  Daniel Henrique Barboza 
  Daniel Letai 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  Eiichi Tsukata 
  Erik Skultety 
  Fabian Affolter 
  Fabian Freyer 
  Fangge Jin 
  Farhan Ali 
  Fedora Weblate Translation 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Ian Wienand 
  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 
  Laine Stump 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Lin Ma 
  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 
  Neal Gompa 
  Nick Shyrokovskiy 
  Nickys Music Group 
  Nico Pache 
  Nikolay Shirokovskiy 
  Olaf Hering 
  Olesya Gerasimenko 
  Orion Poplawski 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  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 
  Shalini Chellathurai Saroja 
  Shaojun Yang 
  Shi Lei 
  Simon Gaiser 
  Stefan Bader 
  Stefan Berger 
  Szymon Scholz 
  Thomas Huth 
  Tim Wiederhake 
  Tomáš Golembiovský 
  Tomáš Janoušek 
  Tuguoyi 
  Wang Xin 
  Weblate 
  Yang Hang 
  Yanqiu Zhang 
  Yi Li 
  Yi Wang 
  Yuri Chornoivan 
  Zheng Chuan 
  zhenwei pi 
  Zhenyu Zheng 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvops

Re: [PATCH] ocaml/libs/eventchn: drop unneeded evtchn.h

[Christian Lindig]

Acked-by: Christian Lindig 


From: Manuel Bouyer 
Sent: 12 January 2021 18:12
To: xen-devel@lists.xenproject.org
Cc: Manuel Bouyer; Christian Lindig; David Scott; Ian Jackson; Wei Liu
Subject: [PATCH] ocaml/libs/eventchn: drop unneeded evtchn.h

From: Manuel Bouyer 

On NetBSD xen/sys/evtchn.h is not available any more. Just remove it as it's
not needed.

Signed-off-by: Manuel Bouyer 

---
 tools/ocaml/libs/eventchn/xeneventchn_stubs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/ocaml/libs/eventchn/xeneventchn_stubs.c 
b/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
index ba40078d09..f889a7a2e4 100644
--- a/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
+++ b/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 #define CAML_NAME_SPACE
--
2.29.2

Re: [PATCH] ocaml/libs/eventchn: drop unneeded evtchn.h

[Manuel Bouyer]

On Wed, Jan 13, 2021 at 09:22:38AM +, Christian Lindig wrote:
> Acked-by: Christian Lindig 

thanks. What should I do now, submit a new patch with this tag, or just wait
for it to be commited ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

[xen-unstable-coverity test] 158404: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  414be7b66349e7dca42bc1fd47c2b2f5b2d27432
baseline version:
 xen  ce59e3dda5f99afbe7257e1e9a22dffd5c4d033c

Last test of basis   158320  2021-01-10 09:18:27 Z3 days
Testing same since   158404  2021-01-13 09:20:27 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 
  Oleksandr Tyshchenko 
  Roger Pau Monné 
  Stefano Stabellini 
  Stefano Stabellini 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   ce59e3dda5..414be7b663  414be7b66349e7dca42bc1fd47c2b2f5b2d27432 -> 
coverity-tested/smoke

Re: [PATCH RFC 0/3] xen: add hypfs per-domain abi-features

[Jürgen Groß]

On 08.01.21 16:44, Jan Beulich wrote:

On 09.12.2020 17:16, Juergen Gross wrote:

This small series is meant as an example how to add further dynamical
directories to hypfs. It can be used to replace Paul's current approach
to specify ABI-features via domain create flags and replace those by
hypfs nodes.


Actually, before I look at further of the patches here: I seem
to vaguely recall agreement was reached to stick to Paul's
approach for the time being? Or am I misremembering?


This is my understanding, too.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3 1/5] xen: Fix event channel callback via INTX/GSI

[Jürgen Groß]

On 06.01.21 16:39, David Woodhouse wrote:

From: David Woodhouse 

For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().

We tend to get away with this on Xen versions below 4.0 because we avoid
calling xs_reset_watches() anyway, because xenstore might not cope with
reading a non-existent key. And newer Xen *does* have the vector
callback support, so we rarely fall back to INTX/GSI delivery.

To fix it, clean up a bit of the mess of xs_init() and xenbus_probe()
startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM
case, deferring it to be called from xenbus_probe() in the XS_HVM case
instead.

Then fix up the invocation of xenbus_probe() to happen either from its
device_initcall if the callback is available early enough, or when the
callback is finally set up. This means that the hack of calling
xenbus_probe() from a workqueue after the first interrupt, or directly
from the PCI platform device setup, is no longer needed.

Signed-off-by: David Woodhouse 
Reviewed-by: Boris Ostrovsky 


Building for arm I get:

/home/gross/korg/src/drivers/xen/xenbus/xenbus_probe.c: In function 
'xenbus_probe_initcall':
/home/gross/korg/src/drivers/xen/xenbus/xenbus_probe.c:711:41: error: 
'xen_have_vector_callback' undeclared (first use in this function); did 
you mean 'em_data_callback'?

   (!IS_ENABLED(CONFIG_XEN_PVHVM) || xen_have_vector_callback)))


Juergen


---
  arch/arm/xen/enlighten.c  |  2 +-
  drivers/xen/events/events_base.c  | 10 -
  drivers/xen/platform-pci.c|  1 -
  drivers/xen/xenbus/xenbus.h   |  1 +
  drivers/xen/xenbus/xenbus_comms.c |  8 
  drivers/xen/xenbus/xenbus_probe.c | 68 ---
  include/xen/xenbus.h  |  2 +-
  7 files changed, 57 insertions(+), 35 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 60e901cd0de6..5a957a9a0984 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -371,7 +371,7 @@ static int __init xen_guest_init(void)
}
gnttab_init();
if (!xen_initial_domain())
-   xenbus_probe(NULL);
+   xenbus_probe();
  
  	/*

 * Making sure board specific code will not set up ops for
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index a8030332a191..e850f79351cb 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2060,16 +2060,6 @@ static struct irq_chip xen_percpu_chip __read_mostly = {
.irq_ack= ack_dynirq,
  };
  
-int xen_set_callback_via(uint64_t via)

-{
-   struct xen_hvm_param a;
-   a.domid = DOMID_SELF;
-   a.index = HVM_PARAM_CALLBACK_IRQ;
-   a.value = via;
-   return HYPERVISOR_hvm_op(HVMOP_set_param, &a);
-}
-EXPORT_SYMBOL_GPL(xen_set_callback_via);
-
  #ifdef CONFIG_XEN_PVHVM
  /* Vector callbacks are better than PCI interrupts to receive event
   * channel notifications because we can receive vector callbacks on any
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index dd911e1ff782..9db557b76511 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -149,7 +149,6 @@ static int platform_pci_probe(struct pci_dev *pdev,
ret = gnttab_init();
if (ret)
goto grant_out;
-   xenbus_probe(NULL);
return 0;
  grant_out:
gnttab_free_auto_xlat_frames();
diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 2a93b7c9c159..dc1537335414 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -115,6 +115,7 @@ int xenbus_probe_node(struct xen_bus_type *bus,
  const char *type,
  const char *nodename);
  int xenbus_probe_devices(struct xen_bus_type *bus);
+void xenbus_probe(void);
  
  void xenbus_dev_changed(const char *node, struct xen_bus_type *bus);
  
diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c

index eb5151fc8efa..e5fda0256feb 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -57,16 +57,8 @@ DEFINE_MUTEX(xs_response_mutex);
  static int xenbus_irq;
  static struct task_struct *xenbus_task;
  
-static DECLARE_WORK(probe_work, xenbus_probe);

-
-
  static irqreturn_t wake_waiting(int irq, void *unused)
  {
-   if (unlikely(xenstored_ready == 0)) {
-   xenstored_ready = 1;
-   schedule_work(&probe_work);
-   }
-
wake_up(&xb_waitq);
return IRQ_HANDLED;
  }
diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index 44634d970a5c..b1b5b6fe9b52 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -683,29 +683,63 @@ void unregister_xenstore_notifier(struct notif

Re: [PATCH v2] xen/privcmd: allow fetching resource sizes

[Jürgen Groß]

On 12.01.21 12:53, Roger Pau Monne wrote:

Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
addr = 0 in order to fetch the size of a specific resource.

Add a shortcut to the default map resource path, since fetching the
size requires no address to be passed in, and thus no VMA to setup.

This is missing from the initial implementation, and causes issues
when mapping resources that don't have fixed or known sizes.

Signed-off-by: Roger Pau Monné 
Cc: sta...@vger.kernel.org # >= 4.18


Pushed to xen/tip.git for-linus-5.11


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [RFC PATCH v3 1/6] swiotlb: Add io_tlb_mem struct

[Christoph Hellwig]

On Wed, Jan 06, 2021 at 11:41:19AM +0800, Claire Chang wrote:
> Added a new struct, io_tlb_mem, as the IO TLB memory pool descriptor and
> moved relevant global variables into that struct.
> This will be useful later to allow for restricted DMA pool.

I like where this is going, but a few comments.

Mostly I'd love to be able to entirely hide io_tlb_default_mem
and struct io_tlb_mem inside of swiotlb.c.

> --- a/arch/powerpc/platforms/pseries/svm.c
> +++ b/arch/powerpc/platforms/pseries/svm.c
> @@ -55,8 +55,8 @@ void __init svm_swiotlb_init(void)
>   if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, false))
>   return;
>  
> - if (io_tlb_start)
> - memblock_free_early(io_tlb_start,
> + if (io_tlb_default_mem.start)
> + memblock_free_early(io_tlb_default_mem.start,
>   PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));

I think this should switch to use the local vstart variable in
prep patch.

>   panic("SVM: Cannot allocate SWIOTLB buffer");
>  }
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 2b385c1b4a99..4d17dff7ffd2 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -192,8 +192,8 @@ int __ref xen_swiotlb_init(int verbose, bool early)
>   /*
>* IO TLB memory already allocated. Just use it.
>*/
> - if (io_tlb_start != 0) {
> - xen_io_tlb_start = phys_to_virt(io_tlb_start);
> + if (io_tlb_default_mem.start != 0) {
> + xen_io_tlb_start = phys_to_virt(io_tlb_default_mem.start);
>   goto end;

xen_io_tlb_start is interesting. It is used only in two functions:

 1) is_xen_swiotlb_buffer, where I think we should be able to just use
is_swiotlb_buffer instead of open coding it with the extra
phys_to_virt/virt_to_phys cycle.
 2) xen_swiotlb_init, where except for the assignment it only is used
locally for the case not touched above and could this be replaced
with a local variable.

Konrad, does this make sense to you?

>  static inline bool is_swiotlb_buffer(phys_addr_t paddr)
>  {
> - return paddr >= io_tlb_start && paddr < io_tlb_end;
> + struct io_tlb_mem *mem = &io_tlb_default_mem;
> +
> + return paddr >= mem->start && paddr < mem->end;

We'd then have to move this out of line as well.

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Christoph Hellwig]

On Wed, Jan 06, 2021 at 08:50:03AM +0100, Greg KH wrote:
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -413,6 +413,7 @@ struct dev_links_info {
> >   * @dma_pools: Dma pools (if dma'ble device).
> >   * @dma_mem:   Internal for coherent mem override.
> >   * @cma_area:  Contiguous memory area for dma allocations
> > + * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
> 
> Why does this have to be added here?  Shouldn't the platform-specific
> code handle it instead?

The whole code added here is pretty generic.  What we need to eventually
do, though is to add a separate dma_device instead of adding more and more
bloat to struct device.

Re: [PATCH v3 1/5] xen: Fix event channel callback via INTX/GSI

[David Woodhouse]

On Wed, 2021-01-13 at 12:20 +0100, Jürgen Groß wrote:
> 
> /home/gross/korg/src/drivers/xen/xenbus/xenbus_probe.c: In function 
> 'xenbus_probe_initcall':
> /home/gross/korg/src/drivers/xen/xenbus/xenbus_probe.c:711:41:
> error: 
> 'xen_have_vector_callback' undeclared (first use in this function);
> did 
> you mean 'em_data_callback'?
> (!IS_ENABLED(CONFIG_XEN_PVHVM) || xen_have_vector_callback)))
> 

Oops. I think this should fix it; will retest and post the series again
with this folded into the offending commit.

Thanks.

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index b1b5b6fe9b52..f3ef23ebcd94 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -699,16 +699,30 @@ void xenbus_probe(void)
blocking_notifier_call_chain(&xenstore_chain, 0, NULL);
 }
 
+/*
+ * Returns true when XenStore init must be deferred in order to
+ * allow the PCI platform device to be initialised, before we
+ * can actually have event channel interrupts working.
+ */
+static bool xs_hvm_defer_init_for_callback(void)
+{
+#ifdef CONFIG_XEN_PVHVM
+   return xen_store_domain_type == XS_HVM &&
+   !xen_have_vector_callback;
+#else
+   return false;
+#endif
+}
+
 static int __init xenbus_probe_initcall(void)
 {
/*
 * Probe XenBus here in the XS_PV case, and also XS_HVM unless we
-* need to wait for the platform PCI device to come up, which is
-* the (XEN_PVPVM && !xen_have_vector_callback) case.
+* need to wait for the platform PCI device to come up.
 */
if (xen_store_domain_type == XS_PV ||
-   (xen_store_domain_type == XS_HVM &&
-(!IS_ENABLED(CONFIG_XEN_PVHVM) || xen_have_vector_callback)))
+   (xen_store_domain_type == XS_HVM &&
+!xs_hvm_defer_init_for_callback())
xenbus_probe();
 
return 0;
@@ -732,8 +746,7 @@ int xen_set_callback_via(uint64_t via)
 * If xenbus_probe_initcall() deferred the xenbus_probe()
 * due to the callback not functioning yet, we can do it now.
 */
-   if (!xenstored_ready && xen_store_domain_type == XS_HVM &&
-   IS_ENABLED(CONFIG_XEN_PVHVM) && !xen_have_vector_callback)
+   if (!xenstored_ready && xs_hvm_defer_init_for_callback())
xenbus_probe();
 
return ret;


smime.p7s
Description: S/MIME cryptographic signature

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Greg KH]

On Wed, Jan 13, 2021 at 12:51:26PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 06, 2021 at 08:50:03AM +0100, Greg KH wrote:
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -413,6 +413,7 @@ struct dev_links_info {
> > >   * @dma_pools:   Dma pools (if dma'ble device).
> > >   * @dma_mem: Internal for coherent mem override.
> > >   * @cma_area:Contiguous memory area for dma allocations
> > > + * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
> > 
> > Why does this have to be added here?  Shouldn't the platform-specific
> > code handle it instead?
> 
> The whole code added here is pretty generic.  What we need to eventually
> do, though is to add a separate dma_device instead of adding more and more
> bloat to struct device.

I have no objections for that happening!

[PATCH 3/3] tools: Move memshrtool from tests/ to misc/

[Andrew Cooper]

memshrtool is a tool for a human to use, rather than a test.  Move it into
misc/ as a more appropriate location to live.  Also rename it to
xen-memshare-tool

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 

I'm debating dropping the tool suffix, because I don't think that's much help
either.
---
 .gitignore |  1 -
 tools/misc/.gitignore  |  1 +
 tools/misc/Makefile|  4 +++
 .../memshrtool.c => misc/xen-memshare-tool.c}  |  0
 tools/tests/Makefile   |  1 -
 tools/tests/mem-sharing/Makefile   | 31 --
 6 files changed, 5 insertions(+), 33 deletions(-)
 rename tools/{tests/mem-sharing/memshrtool.c => misc/xen-memshare-tool.c} 
(100%)
 delete mode 100644 tools/tests/mem-sharing/Makefile

diff --git a/.gitignore b/.gitignore
index 630bdf5b99..35957cc21f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -273,7 +273,6 @@ tools/tests/x86_emulator/test_x86_emulator
 tools/tests/x86_emulator/x86_emulate
 tools/tests/x86_emulator/xop*.[ch]
 tools/tests/xenstore/xs-test
-tools/tests/mem-sharing/memshrtool
 tools/tests/mce-test/tools/xen-mceinj
 tools/tests/vpci/list.h
 tools/tests/vpci/vpci.[hc]
diff --git a/tools/misc/.gitignore b/tools/misc/.gitignore
index e332ed4ec7..a01bc5b5b5 100644
--- a/tools/misc/.gitignore
+++ b/tools/misc/.gitignore
@@ -1,2 +1,3 @@
 xen-access
+xen-memshare-tool
 xen-ucode
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 612b7002e5..fbe010a55a 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -32,6 +32,7 @@ INSTALL_SBIN   += xenpm
 INSTALL_SBIN   += xenwatchdogd
 INSTALL_SBIN   += xen-access
 INSTALL_SBIN   += xen-livepatch
+INSTALL_SBIN   += xen-memshare-tool
 INSTALL_SBIN   += xen-diag
 INSTALL_SBIN += $(INSTALL_SBIN-y)
 
@@ -86,6 +87,9 @@ xen-hvmctx: xen-hvmctx.o
 xen-hvmcrash: xen-hvmcrash.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+xen-memshare-tool: xen-memshare-tool.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 xenperf: xenperf.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
diff --git a/tools/tests/mem-sharing/memshrtool.c 
b/tools/misc/xen-memshare-tool.c
similarity index 100%
rename from tools/tests/mem-sharing/memshrtool.c
rename to tools/misc/xen-memshare-tool.c
diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index 771715be0f..fc9b715951 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -4,7 +4,6 @@ include $(XEN_ROOT)/tools/Rules.mk
 SUBDIRS-y :=
 SUBDIRS-$(CONFIG_X86) += cpu-policy
 SUBDIRS-$(CONFIG_X86) += mce-test
-SUBDIRS-y += mem-sharing
 ifneq ($(clang),y)
 SUBDIRS-$(CONFIG_X86) += x86_emulator
 endif
diff --git a/tools/tests/mem-sharing/Makefile b/tools/tests/mem-sharing/Makefile
deleted file mode 100644
index 5cd96e4cc9..00
--- a/tools/tests/mem-sharing/Makefile
+++ /dev/null
@@ -1,31 +0,0 @@
-XEN_ROOT=$(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-CFLAGS += -Werror
-
-CFLAGS += $(CFLAGS_libxenctrl)
-CFLAGS += $(CFLAGS_xeninclude)
-
-TARGETS-y := 
-TARGETS-$(CONFIG_X86) += memshrtool
-TARGETS := $(TARGETS-y)
-
-.PHONY: all
-all: build
-
-.PHONY: build
-build: $(TARGETS)
-
-.PHONY: clean
-clean:
-   $(RM) *.o $(TARGETS) *~ $(DEPS_RM)
-
-.PHONY: distclean
-distclean: clean
-
-memshrtool: memshrtool.o
-   $(CC) -o $@ $< $(LDFLAGS) $(LDLIBS_libxenctrl)
-
--include $(DEPS_INCLUDE)
-
-install uninstall:
-- 
2.11.0

[PATCH 0/3] Cleanup to tools/tests

[Andrew Cooper]

Move two non-test things out of tests/ and drop some obsolete infrastructure.

Andrew Cooper (3):
  tools/tests: Drop obsolete running scripts
  tools: Move xen-access from tests/ to misc/
  tools: Move memshrtool from tests/ to misc/

 .gitignore |  5 --
 tools/misc/.gitignore  |  2 +
 tools/misc/Makefile|  8 +++
 tools/{tests/xen-access => misc}/xen-access.c  |  1 +
 .../memshrtool.c => misc/xen-memshare-tool.c}  |  0
 tools/tests/Makefile   |  5 --
 tools/tests/mem-sharing/Makefile   | 31 ---
 tools/tests/run_tests.sh   | 61 --
 tools/tests/utests/run_all_tests.py| 23 
 tools/tests/xen-access/Makefile| 33 
 10 files changed, 11 insertions(+), 158 deletions(-)
 rename tools/{tests/xen-access => misc}/xen-access.c (99%)
 rename tools/{tests/mem-sharing/memshrtool.c => misc/xen-memshare-tool.c} 
(100%)
 delete mode 100644 tools/tests/mem-sharing/Makefile
 delete mode 100644 tools/tests/run_tests.sh
 delete mode 100644 tools/tests/utests/run_all_tests.py
 delete mode 100644 tools/tests/xen-access/Makefile

-- 
2.11.0

[PATCH 2/3] tools: Move xen-access from tests/ to misc/

[Andrew Cooper]

xen-access is a tool for a human to use, rather than a test.  Move it
into misc/ as a more appropriate location to live.

Move the -DXC_WANT_COMPAT_DEVICEMODEL_API from CFLAGS into xen-access.c itself
to avoid adding Makefile complexity.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Tamas K Lengyel 
---
 .gitignore|  1 -
 tools/misc/.gitignore |  1 +
 tools/misc/Makefile   |  4 
 tools/{tests/xen-access => misc}/xen-access.c |  1 +
 tools/tests/Makefile  |  1 -
 tools/tests/xen-access/Makefile   | 33 ---
 6 files changed, 6 insertions(+), 35 deletions(-)
 rename tools/{tests/xen-access => misc}/xen-access.c (99%)
 delete mode 100644 tools/tests/xen-access/Makefile

diff --git a/.gitignore b/.gitignore
index 1b54ea3111..630bdf5b99 100644
--- a/.gitignore
+++ b/.gitignore
@@ -272,7 +272,6 @@ tools/tests/x86_emulator/*sse*.[ch]
 tools/tests/x86_emulator/test_x86_emulator
 tools/tests/x86_emulator/x86_emulate
 tools/tests/x86_emulator/xop*.[ch]
-tools/tests/xen-access/xen-access
 tools/tests/xenstore/xs-test
 tools/tests/mem-sharing/memshrtool
 tools/tests/mce-test/tools/xen-mceinj
diff --git a/tools/misc/.gitignore b/tools/misc/.gitignore
index c5fe2cfccd..e332ed4ec7 100644
--- a/tools/misc/.gitignore
+++ b/tools/misc/.gitignore
@@ -1 +1,2 @@
+xen-access
 xen-ucode
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 7d37f297a9..612b7002e5 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -30,6 +30,7 @@ INSTALL_SBIN   += xenlockprof
 INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
 INSTALL_SBIN   += xenwatchdogd
+INSTALL_SBIN   += xen-access
 INSTALL_SBIN   += xen-livepatch
 INSTALL_SBIN   += xen-diag
 INSTALL_SBIN += $(INSTALL_SBIN-y)
@@ -73,6 +74,9 @@ clean:
 .PHONY: distclean
 distclean: clean
 
+xen-access: xen-access.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) 
$(LDLIBS_libxenevtchn) $(APPEND_LDFLAGS)
+
 xen-cpuid: xen-cpuid.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) 
$(APPEND_LDFLAGS)
 
diff --git a/tools/tests/xen-access/xen-access.c b/tools/misc/xen-access.c
similarity index 99%
rename from tools/tests/xen-access/xen-access.c
rename to tools/misc/xen-access.c
index 1ab4f6705f..4bbef0bd2e 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/misc/xen-access.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 
+#define XC_WANT_COMPAT_DEVICEMODEL_API
 #include 
 #include 
 #include 
diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index 9077fa14d3..771715be0f 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -8,7 +8,6 @@ SUBDIRS-y += mem-sharing
 ifneq ($(clang),y)
 SUBDIRS-$(CONFIG_X86) += x86_emulator
 endif
-SUBDIRS-y += xen-access
 SUBDIRS-y += xenstore
 SUBDIRS-y += depriv
 SUBDIRS-$(CONFIG_HAS_PCI) += vpci
diff --git a/tools/tests/xen-access/Makefile b/tools/tests/xen-access/Makefile
deleted file mode 100644
index 131c9f375d..00
--- a/tools/tests/xen-access/Makefile
+++ /dev/null
@@ -1,33 +0,0 @@
-XEN_ROOT=$(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-CFLAGS += -Werror
-CFLAGS += -DXC_WANT_COMPAT_DEVICEMODEL_API
-
-CFLAGS += $(CFLAGS_libxenctrl)
-CFLAGS += $(CFLAGS_libxenguest)
-CFLAGS += $(CFLAGS_libxenevtchn)
-CFLAGS += $(CFLAGS_xeninclude)
-
-TARGETS-y := xen-access
-TARGETS := $(TARGETS-y)
-
-.PHONY: all
-all: build
-
-.PHONY: build
-build: $(TARGETS)
-
-.PHONY: clean
-clean:
-   $(RM) *.o $(TARGETS) *~ $(DEPS_RM)
-
-.PHONY: distclean
-distclean: clean
-
-xen-access: xen-access.o Makefile
-   $(CC) -o $@ $< $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) 
$(LDLIBS_libxenevtchn)
-
-install uninstall:
-
--include $(DEPS_INCLUDE)
-- 
2.11.0

[PATCH 1/3] tools/tests: Drop obsolete running scripts

[Andrew Cooper]

The python unit tests were dropped in Xen 4.12 due to being obsolete, but the
scripts to run the tests were missed.  Clean up .gitignore as well

Also drop the libxenctrl {C,LD}FLAGS adjustments in the Makefile.  This logic
isn't used, and isn't appropriate even in principle, as there are tests in
here which don't want to use libxenctrl.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
---
 .gitignore  |  3 --
 tools/tests/Makefile|  3 --
 tools/tests/run_tests.sh| 61 -
 tools/tests/utests/run_all_tests.py | 23 --
 4 files changed, 90 deletions(-)
 delete mode 100644 tools/tests/run_tests.sh
 delete mode 100644 tools/tests/utests/run_all_tests.py

diff --git a/.gitignore b/.gitignore
index b169d78ed7..1b54ea3111 100644
--- a/.gitignore
+++ b/.gitignore
@@ -274,9 +274,6 @@ tools/tests/x86_emulator/x86_emulate
 tools/tests/x86_emulator/xop*.[ch]
 tools/tests/xen-access/xen-access
 tools/tests/xenstore/xs-test
-tools/tests/regression/installed/*
-tools/tests/regression/build/*
-tools/tests/regression/downloads/*
 tools/tests/mem-sharing/memshrtool
 tools/tests/mce-test/tools/xen-mceinj
 tools/tests/vpci/list.h
diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index ed3bed404b..9077fa14d3 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -1,9 +1,6 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS  += $(CFLAGS_libxenctrl)
-LDLIBS += $(LDLIBS_libxenctrl)
-
 SUBDIRS-y :=
 SUBDIRS-$(CONFIG_X86) += cpu-policy
 SUBDIRS-$(CONFIG_X86) += mce-test
diff --git a/tools/tests/run_tests.sh b/tools/tests/run_tests.sh
deleted file mode 100644
index c492876b4b..00
--- a/tools/tests/run_tests.sh
+++ /dev/null
@@ -1,61 +0,0 @@
-#!/bin/bash
-#
-# This runs the available unit-tests with all different supported
-# python versions.
-# 
-# To run this this must be 'cd'ed to the tests directory.
-#
-
-ENABLE_UNSUPPORTED=0
-
-function usage()
-{
-printf "Usage: %s: [-u]\n" $0
-printf "   -u: run test with unsupported python versions also\n"
-}
-
-function run_one_test()
-{
-PYTHON=$1
-PYTHON_EXECUTABLE=`echo $PYTHON | tr -d "-"`
-echo "+++ Running tests with $PYTHON"
-export LD_LIBRARY_PATH=./regression/installed/$PYTHON/lib
-./regression/installed/$PYTHON/bin/$PYTHON_EXECUTABLE \
-   utests/run_all_tests.py
-echo "--- Finished tests with $PYTHON"
-}
-
-function run_all_tests()
-{
-for PYTHON in $@;
-do
-   run_one_test $PYTHON
-done
-}
-
-while getopts u name
-do
-case $name in
-   h)  usage; exit 0;;
-   u)  ENABLE_UNSUPPORTED=1;;
-   ?)  usage; exit 2;;
-esac
-done
-
-# Build the different python versions
-(cd regression && make -j4 runtime-environment)
-
-# Supported: when an unit test fails this should be seen as an error
-PYTHON_SUPPORTED="python-2.4 python-2.5 python-2.6"
-# Unsupported: failure should be seen as a hint
-PYTHON_UNSUPPORTED="python-3.1"
-
-export PYTHONPATH=`echo $PWD/../python/build/lib.*`:$PWD
-
-set -e
-run_all_tests $PYTHON_SUPPORTED
-
-if test $ENABLE_UNSUPPORTED -eq 1
-then
-run_all_tests $PYTHON_UNSUPPORTED
-fi
diff --git a/tools/tests/utests/run_all_tests.py 
b/tools/tests/utests/run_all_tests.py
deleted file mode 100644
index 7318c81ff2..00
--- a/tools/tests/utests/run_all_tests.py
+++ /dev/null
@@ -1,23 +0,0 @@
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of version 2.1 of the GNU Lesser General Public
-# License as published by the Free Software Foundation.
-#
-# This library 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
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; If not, see .
-#
-# Copyright (C) 2009 flonatel GmbH & Co. KG
-#
-
-import unittest
-
-suite = unittest.TestSuite([])
-
-if __name__ == "__main__":
-testresult = unittest.TextTestRunner(verbosity=3).run(suite)
-
-- 
2.11.0

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Christoph Hellwig]

On Wed, Jan 13, 2021 at 01:29:05PM +0100, Greg KH wrote:
> > > Why does this have to be added here?  Shouldn't the platform-specific
> > > code handle it instead?
> > 
> > The whole code added here is pretty generic.  What we need to eventually
> > do, though is to add a separate dma_device instead of adding more and more
> > bloat to struct device.
> 
> I have no objections for that happening!

I'm pretty sure you agreed to it before in fact.  Now someone just needs
to find the time to do this heavy lifting, where "someone" probably means
me.

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Christoph Hellwig]

> +#ifdef CONFIG_SWIOTLB
> + struct io_tlb_mem   *dma_io_tlb_mem;
>  #endif

Please add a new config option for this code instead of always building
it when swiotlb is enabled.

> +static int swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start,
> +size_t size)

Can you split the refactoring in swiotlb.c into one or more prep
patches?

> +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> + struct device *dev)
> +{
> + struct io_tlb_mem *mem = rmem->priv;
> + int ret;
> +
> + if (dev->dma_io_tlb_mem)
> + return -EBUSY;
> +
> + if (!mem) {
> + mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> + if (!mem)
> + return -ENOMEM;

What is the calling convention here that allows for a NULL and non-NULL
private data?

Re: [RFC PATCH v3 3/6] swiotlb: Use restricted DMA pool if available

[Christoph Hellwig]

> +#ifdef CONFIG_SWIOTLB
> + if (unlikely(swiotlb_force == SWIOTLB_FORCE) || dev->dma_io_tlb_mem)
>   return swiotlb_map(dev, phys, size, dir, attrs);
> +#endif

Please provide a wrapper for the dev->dma_io_tlb_mem check that
always returns false if the per-device swiotlb support is not enabled.

> index 7fb2ac087d23..1f05af09e61a 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -222,7 +222,6 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long 
> nslabs, int verbose)
>   mem->orig_addr[i] = INVALID_PHYS_ADDR;
>   }
>   mem->index = 0;
> - no_iotlb_memory = false;

How does this fit in here?

Re: [RFC PATCH v3 4/6] swiotlb: Add restricted DMA alloc/free support.

[Christoph Hellwig]

> +#ifdef CONFIG_SWIOTLB
> + if (unlikely(dev->dma_io_tlb_mem))
> + return swiotlb_alloc(dev, size, dma_handle, attrs);
> +#endif

Another place where the dma_io_tlb_mem is useful to avoid the ifdef.

> -phys_addr_t swiotlb_tbl_map_single(struct device *hwdev, phys_addr_t 
> orig_addr,
> - size_t mapping_size, size_t alloc_size,
> - enum dma_data_direction dir, unsigned long attrs)
> +static int swiotlb_tbl_find_free_region(struct device *hwdev,
> + dma_addr_t tbl_dma_addr,
> + size_t alloc_size,
> + unsigned long attrs)

> +static void swiotlb_tbl_release_region(struct device *hwdev, int index,
> +size_t size)

This refactoring should be another prep patch.


> +void *swiotlb_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
> + unsigned long attrs)

I'd rather have the names convey there are for the per-device bounce
buffer in some form.

> + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;

While we're at it I wonder if the io_tlb is something we could change
while we're at it.  Maybe replace io_tlb_mem with struct swiotlb
and rename the field in struct device to dev_swiotlb?

> + int index;
> + void *vaddr;
> + phys_addr_t tlb_addr;
> +
> + size = PAGE_ALIGN(size);
> + index = swiotlb_tbl_find_free_region(dev, mem->start, size, attrs);
> + if (index < 0)
> + return NULL;
> +
> + tlb_addr = mem->start + (index << IO_TLB_SHIFT);
> + *dma_handle = phys_to_dma_unencrypted(dev, tlb_addr);
> +
> + if (!dev_is_dma_coherent(dev)) {
> + unsigned long pfn = PFN_DOWN(tlb_addr);
> +
> + /* remove any dirty cache lines on the kernel alias */
> + arch_dma_prep_coherent(pfn_to_page(pfn), size);

Can we hook in somewhat lower level in the dma-direct code so that all
the remapping in dma-direct can be reused instead of duplicated?  That
also becomes important if we want to use non-remapping uncached support,
e.g. on mips or x86, or the direct changing of the attributes that Will
planned to look into for arm64.

Re: [PATCH 3/3] tools: Move memshrtool from tests/ to misc/

[Ian Jackson]

Andrew Cooper writes ("[PATCH 3/3] tools: Move memshrtool from tests/ to 
misc/"):
> memshrtool is a tool for a human to use, rather than a test.  Move it into
> misc/ as a more appropriate location to live.  Also rename it to
> xen-memshare-tool

Acked-by: Ian Jackson 

Re: [PATCH 1/3] tools/tests: Drop obsolete running scripts

[Ian Jackson]

Andrew Cooper writes ("[PATCH 1/3] tools/tests: Drop obsolete running scripts"):
> The python unit tests were dropped in Xen 4.12 due to being obsolete, but the
> scripts to run the tests were missed.  Clean up .gitignore as well

I'm happy with this part.

> Also drop the libxenctrl {C,LD}FLAGS adjustments in the Makefile.  This logic
> isn't used, and isn't appropriate even in principle, as there are tests in
> here which don't want to use libxenctrl.

It's not clear to me that it's EBW to link all the tests to libxenctrl
simply to make the build easier.

In a later patch you add these settings back as part of a particular
test target.

I don't much mind it being done this way, and you've done the work, so
I am giving this my ack, but I just wanted to register my qualm in
case you had a second thought.

FTR, however, IMO the -DXC_WANT_COMPAT_DEVICEMODEL_API that you move
to a specific test program in a later patch is something that ought
not to be applied to all tests, so there doing it that way is
necessary - thanks.

Acked-by: Ian Jackson 

Ian.

Re: [PATCH 2/3] tools: Move xen-access from tests/ to misc/

[Ian Jackson]

Andrew Cooper writes ("[PATCH 2/3] tools: Move xen-access from tests/ to 
misc/"):
> xen-access is a tool for a human to use, rather than a test.  Move it
> into misc/ as a more appropriate location to live.
> 
> Move the -DXC_WANT_COMPAT_DEVICEMODEL_API from CFLAGS into xen-access.c itself
> to avoid adding Makefile complexity.

Acked-by: Ian Jackson 

Re: [PATCH] x86/dpci: remove the dpci EOI timer

[Roger Pau Monné]

On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne 
> > Sent: Wednesday, January 13, 2021 1:33 AM
> > 
> > Current interrupt pass though code will setup a timer for each
> > interrupt injected to the guest that requires an EOI from the guest.
> > Such timer would perform two actions if the guest doesn't EOI the
> > interrupt before a given period of time. The first one is deasserting
> > the virtual line, the second is perform an EOI of the physical
> > interrupt source if it requires such.
> > 
> > The deasserting of the guest virtual line is wrong, since it messes
> > with the interrupt status of the guest. It's not clear why this was
> > odne in the first place, it should be the guest the one to EOI the
> > interrupt and thus deassert the line.
> > 
> > Performing an EOI of the physical interrupt source is redundant, since
> > there's already a timer that takes care of this for all interrupts,
> > not just the HVM dpci ones, see irq_guest_action_t struct eoi_timer
> > field.
> > 
> > Since both of the actions performed by the dpci timer are not
> > required, remove it altogether.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > As with previous patches, I'm having a hard time figuring out why this
> > was required in the first place. I see no reason for Xen to be
> > deasserting the guest virtual line. There's a comment:
> > 
> > /*
> >  * Set a timer to see if the guest can finish the interrupt or not. For
> >  * example, the guest OS may unmask the PIC during boot, before the
> >  * guest driver is loaded. hvm_pci_intx_assert() may succeed, but the
> >  * guest will never deal with the irq, then the physical interrupt line
> >  * will never be deasserted.
> >  */
> > 
> > Did this happen because the device was passed through in a bogus state
> > where it would generate interrupts without the guest requesting
> 
> It could be a case where two devices share the same interrupt line and
> are assigned to different domains. In this case, the interrupt activity of 
> two devices interfere with each other.

This would also seem to be problematic if the device decides to use
MSI instead of INTx, but due to the shared nature of the INTx line we
would continue to inject INTx (generated from another device not
passed through to the guest) to the guest even if the device has
switched to MSI.

> > 
> > Won't the guest face the same issues when booted on bare metal, and
> > thus would already have the means to deal with such issues?
> 
> The original commit was added by me in ~13yrs ago (0f843ba00c95)
> when enabling Xen in a client virtualization environment where interrupt
> sharing is popular.

Thanks, the reference to the above commit is helpful, I wasn't able to
find it and it contains a comment that I think has been lost, which
provides the background on why this was added.

> I believe above comment was recorded for a real 
> problem at the moment (deassert resets the intx line to unblock further
> interrupts). But I'm not sure whether it is still the case after both Xen and 
> guest OS have changed a lot. At least some test from people who
> still use Xen in shared interrupt scenario would be helpful. Or, if such
> usage is already niche, maybe we can consider disallow passing through
> devices which share the same interrupt line to different domains and
> then safely remove this dpci EOI trick.

So the deassert done by timeout only deasserts the virtual line, but
doesn't for example clear the IRR bit from the vIO-APIC pin, which
will cause further interrupts to not be delivered anyway until a
proper EOI (or a switch to trigger mode) is done to the pin.

I think it's going to be complicated for me to find a system that has
two devices I can passthrough sharing the same GSI.

It also makes me wonder why do we need to keep all this internal state
about virtual lines and assert counts. Such virtual lines will get
de-asserted when the guest perform an EOI of the interrupt, which also
clear the PIC pending bits and allows further interrupts to be
injected. Wouldn't it be enough to simply try to assert the guest
irq/gsi, and let the interrupt controller decide whether it needs to
inject another interrupt, or there's one already pending?

vIO-APIC has the IRR field which I think it's fairly similar to what
Xen achieves with all the line logic: prevent another interrupt
injection until the current one has been EOI'ed. The i8259 doesn't
have such field, and might indeed end up with an extra interrupt
queued in IRR while there's one still pending in ISR, but I don't
think that would be harmful to the guest.

Thanks, Roger.

Re: [PATCH 1/3] tools/tests: Drop obsolete running scripts

[Andrew Cooper]

On 13/01/2021 13:03, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 1/3] tools/tests: Drop obsolete running 
> scripts"):
>> The python unit tests were dropped in Xen 4.12 due to being obsolete, but the
>> scripts to run the tests were missed.  Clean up .gitignore as well
> I'm happy with this part.
>
>> Also drop the libxenctrl {C,LD}FLAGS adjustments in the Makefile.  This logic
>> isn't used, and isn't appropriate even in principle, as there are tests in
>> here which don't want to use libxenctrl.
> It's not clear to me that it's EBW to link all the tests to libxenctrl
> simply to make the build easier.
>
> In a later patch you add these settings back as part of a particular
> test target.
>
> I don't much mind it being done this way, and you've done the work, so
> I am giving this my ack, but I just wanted to register my qualm in
> case you had a second thought.

These lines aren't used, because this Makefile doesn't compile/link any
code.  They don't apply to subdirs.

More than half the remaining content in tests/ really are unit tests,
and must not be linked against libxc if they want to be run outside of
dom0 (e.g. the developers build box.)

> FTR, however, IMO the -DXC_WANT_COMPAT_DEVICEMODEL_API that you move
> to a specific test program in a later patch is something that ought
> not to be applied to all tests, so there doing it that way is
> necessary - thanks.
>
> Acked-by: Ian Jackson 

Thanks,

~Andrew

Re: Inconsistent console behavior during HVM direct boot

[Roger Pau Monné]

On Tue, Jan 12, 2021 at 09:54:18PM -0500, Tamas K Lengyel wrote:
> While direct booting a Linux kernel into an HVM VM no console output
> is received if serial="pty" is set in the VM config but the kernel
> command line specifies "console=hvc0". If "console=ttyS0" is specified
> then the console output is received as expected. Conversely, if the
> serial line is commented out in the VM config but hvc0 is set on the
> kernel command line then it also works. It's unclear whether this
> behavior is expected or not, after some discussion it sounds like all
> kernels ought to understand hvc0 irrespective of the serial="pty" line
> being set or not. Reporting this in case someone has more insight
> and/or inclination digging into this.

So I think this is (as confusing as it might seem) the intended
behavior.

Using serial='pty' exposes an emulated serial device to the guest and
'xl console' will fetch the output from that device by default. So on
the Linux kernel command line you need to use console=ttyS0 in order
to point Linux to use the emulated serial device.

however if serial='pty' is not used, there will be no emulated serial
device exposed to the guest, only the PV console, and that's what 'xl
console' will attach to in that case. You then need to point the Linux
kernel to use the PV serial console, by adding the console=hvc0
command line.

I'm unsure how to clarify this, maybe some additions could be made to
the xl.cfg man page to note that using serial='pty' will add an
emulated serial device to the guest, and that by default 'xl console'
will fetch the output from that device instead of the paravirtualized
console?

Roger.

Re: [PATCH 3/3] tools: Move memshrtool from tests/ to misc/

[Andrew Cooper]

On 13/01/2021 13:01, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 3/3] tools: Move memshrtool from tests/ to 
> misc/"):
>> memshrtool is a tool for a human to use, rather than a test.  Move it into
>> misc/ as a more appropriate location to live.  Also rename it to
>> xen-memshare-tool
> Acked-by: Ian Jackson 

Thanks, but I expect that Gitlab will tell me that I broke the ARM
build, by losing a "only build this for x86"-ism.

I've folded this delta in to resolve:

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index fbe010a55a..1774ff014f 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -22,6 +22,7 @@ INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmcrash
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx
 INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
+INSTALL_SBIN-$(CONFIG_X86) += xen-memshare-tool
 INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
 INSTALL_SBIN-$(CONFIG_X86) += xen-ucode
 INSTALL_SBIN   += xencov
@@ -32,7 +33,6 @@ INSTALL_SBIN   += xenpm
 INSTALL_SBIN   += xenwatchdogd
 INSTALL_SBIN   += xen-access
 INSTALL_SBIN   += xen-livepatch
-INSTALL_SBIN   += xen-memshare-tool
 INSTALL_SBIN   += xen-diag
 INSTALL_SBIN += $(INSTALL_SBIN-y)
 
~Andrew

[PATCH v4 5/5] x86/xen: Fix xen_hvm_smp_init() when vector callback not available

[David Woodhouse]

From: David Woodhouse 

Only the IPI-related functions in the smp_ops should be conditional
on the vector callback being available. The rest should still happen:

 • xen_hvm_smp_prepare_boot_cpu()

   This function does two things, both of which should still happen if
   there is no vector callback support.

   The call to xen_vcpu_setup() for vCPU0 should still happen as it just
   sets up the vcpu_info for CPU0. That does happen for the secondary
   vCPUs too, from xen_cpu_up_prepare_hvm().

   The second thing it does is call xen_init_spinlocks(), which perhaps
   counter-intuitively should *also* still be happening in the case
   without vector callbacks, so that it can clear its local xen_pvspin
   flag and disable the virt_spin_lock_key accordingly.

   Checking xen_have_vector_callback in xen_init_spinlocks() itself
   would affect PV guests, so set the global nopvspin flag in
   xen_hvm_smp_init() instead, when vector callbacks aren't available.

 • xen_hvm_smp_prepare_cpus()

   This does some IPI-related setup by calling xen_smp_intr_init() and
   xen_init_lock_cpu(), which can be made conditional. And it sets the
   xen_vcpu_id to XEN_VCPU_ID_INVALID for all possible CPUS, which does
   need to happen.

 • xen_smp_cpus_done()

   This offlines any vCPUs which doesn't fit in the global shared_info
   page, if separate vcpu_info placement isn't available. That part also
   needs to happen regardless of vector callback support.

 • xen_hvm_cpu_die()

   This doesn't actually do anything other than commin_cpu_die() right
   right now in the !vector_callback case; all three teardown functions
   it calls should be no-ops. But to guard against future regressions
   it's useful to call it anyway, and for it to explicitly check for
   xen_have_vector_callback before calling those additional functions.

Signed-off-by: David Woodhouse 
Reviewed-by: Boris Ostrovsky 
---
 arch/x86/xen/smp_hvm.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/x86/xen/smp_hvm.c b/arch/x86/xen/smp_hvm.c
index f5e7db4f82ab..056430a1080b 100644
--- a/arch/x86/xen/smp_hvm.c
+++ b/arch/x86/xen/smp_hvm.c
@@ -33,9 +33,11 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int 
max_cpus)
int cpu;
 
native_smp_prepare_cpus(max_cpus);
-   WARN_ON(xen_smp_intr_init(0));
 
-   xen_init_lock_cpu(0);
+   if (xen_have_vector_callback) {
+   WARN_ON(xen_smp_intr_init(0));
+   xen_init_lock_cpu(0);
+   }
 
for_each_possible_cpu(cpu) {
if (cpu == 0)
@@ -50,9 +52,11 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int 
max_cpus)
 static void xen_hvm_cpu_die(unsigned int cpu)
 {
if (common_cpu_die(cpu) == 0) {
-   xen_smp_intr_free(cpu);
-   xen_uninit_lock_cpu(cpu);
-   xen_teardown_timer(cpu);
+   if (xen_have_vector_callback) {
+   xen_smp_intr_free(cpu);
+   xen_uninit_lock_cpu(cpu);
+   xen_teardown_timer(cpu);
+   }
}
 }
 #else
@@ -64,14 +68,17 @@ static void xen_hvm_cpu_die(unsigned int cpu)
 
 void __init xen_hvm_smp_init(void)
 {
-   if (!xen_have_vector_callback)
+   smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
+   smp_ops.smp_prepare_cpus = xen_hvm_smp_prepare_cpus;
+   smp_ops.smp_cpus_done = xen_smp_cpus_done;
+   smp_ops.cpu_die = xen_hvm_cpu_die;
+
+   if (!xen_have_vector_callback) {
+   nopvspin = true;
return;
+   }
 
-   smp_ops.smp_prepare_cpus = xen_hvm_smp_prepare_cpus;
smp_ops.smp_send_reschedule = xen_smp_send_reschedule;
-   smp_ops.cpu_die = xen_hvm_cpu_die;
smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
smp_ops.send_call_func_single_ipi = 
xen_smp_send_call_function_single_ipi;
-   smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
-   smp_ops.smp_cpus_done = xen_smp_cpus_done;
 }
-- 
2.29.2

[PATCH v4 4/5] x86/xen: Don't register Xen IPIs when they aren't going to be used

[David Woodhouse]

From: David Woodhouse 

In the case where xen_have_vector_callback is false, we still register
the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
though they aren't going to be used. Stop doing that.

Signed-off-by: David Woodhouse 
Reviewed-by: Boris Ostrovsky 
---
 arch/x86/xen/enlighten_hvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index ec50b7423a4c..e68ea5f4ad1c 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -164,10 +164,10 @@ static int xen_cpu_up_prepare_hvm(unsigned int cpu)
else
per_cpu(xen_vcpu_id, cpu) = cpu;
rc = xen_vcpu_setup(cpu);
-   if (rc)
+   if (rc || !xen_have_vector_callback)
return rc;
 
-   if (xen_have_vector_callback && xen_feature(XENFEAT_hvm_safe_pvclock))
+   if (xen_feature(XENFEAT_hvm_safe_pvclock))
xen_setup_timer(cpu);
 
rc = xen_smp_intr_init(cpu);
-- 
2.29.2

[PATCH v4 3/5] x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery

[David Woodhouse]

From: David Woodhouse 

It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.

It's also useful for those working on Xen and Xen-compatible hypervisors,
because there are guest kernels still in active use which use PCI INTX
even when vector delivery is available.

Signed-off-by: David Woodhouse 
Reviewed-by: Boris Ostrovsky 
---
 Documentation/admin-guide/kernel-parameters.txt |  4 
 arch/x86/xen/enlighten_hvm.c| 11 ++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index c722ec19cd00..8b9289b27844 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5972,6 +5972,10 @@
This option is obsoleted by the "nopv" option, which
has equivalent effect for XEN platform.
 
+   xen_no_vector_callback
+   [KNL,X86,XEN] Disable the vector callback for Xen
+   event channel interrupts.
+
xen_scrub_pages=[XEN]
Boolean option to control scrubbing pages before giving 
them back
to Xen, for use by other domains. Can be also changed 
at runtime
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 9e87ab010c82..ec50b7423a4c 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -188,6 +188,8 @@ static int xen_cpu_dead_hvm(unsigned int cpu)
return 0;
 }
 
+static bool no_vector_callback __initdata;
+
 static void __init xen_hvm_guest_init(void)
 {
if (xen_pv_domain())
@@ -207,7 +209,7 @@ static void __init xen_hvm_guest_init(void)
 
xen_panic_handler_init();
 
-   if (xen_feature(XENFEAT_hvm_callback_vector))
+   if (!no_vector_callback && xen_feature(XENFEAT_hvm_callback_vector))
xen_have_vector_callback = 1;
 
xen_hvm_smp_init();
@@ -233,6 +235,13 @@ static __init int xen_parse_nopv(char *arg)
 }
 early_param("xen_nopv", xen_parse_nopv);
 
+static __init int xen_parse_no_vector_callback(char *arg)
+{
+   no_vector_callback = true;
+   return 0;
+}
+early_param("xen_no_vector_callback", xen_parse_no_vector_callback);
+
 bool __init xen_hvm_need_lapic(void)
 {
if (xen_pv_domain())
-- 
2.29.2

[PATCH v4 2/5] xen: Set platform PCI device INTX affinity to CPU0

[David Woodhouse]

From: David Woodhouse 

With INTX or GSI delivery, Xen uses the event channel structures of CPU0.

If the interrupt gets handled by Linux on a different CPU, then no events
are seen as pending. Rather than introducing locking to allow other CPUs
to process CPU0's events, just ensure that the PCI interrupts happens
only on CPU0.

Signed-off-by: David Woodhouse 
Reviewed-by: Boris Ostrovsky 
---
 drivers/xen/platform-pci.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 9db557b76511..18f0ed8b1f93 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -132,6 +132,13 @@ static int platform_pci_probe(struct pci_dev *pdev,
dev_warn(&pdev->dev, "request_irq failed err=%d\n", 
ret);
goto out;
}
+   /*
+* It doesn't strictly *have* to run on CPU0 but it sure
+* as hell better process the event channel ports delivered
+* to CPU0.
+*/
+   irq_set_affinity(pdev->irq, cpumask_of(0));
+
callback_via = get_callback_via(pdev);
ret = xen_set_callback_via(callback_via);
if (ret) {
-- 
2.29.2

[PATCH v4 1/5] xen: Fix event channel callback via INTX/GSI

[David Woodhouse]

From: David Woodhouse 

For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().

We tend to get away with this on Xen versions below 4.0 because we avoid
calling xs_reset_watches() anyway, because xenstore might not cope with
reading a non-existent key. And newer Xen *does* have the vector
callback support, so we rarely fall back to INTX/GSI delivery.

To fix it, clean up a bit of the mess of xs_init() and xenbus_probe()
startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM
case, deferring it to be called from xenbus_probe() in the XS_HVM case
instead.

Then fix up the invocation of xenbus_probe() to happen either from its
device_initcall if the callback is available early enough, or when the
callback is finally set up. This means that the hack of calling
xenbus_probe() from a workqueue after the first interrupt, or directly
from the PCI platform device setup, is no longer needed.

Signed-off-by: David Woodhouse 
Reviewed-by: Boris Ostrovsky 
---
 arch/arm/xen/enlighten.c  |  2 +-
 drivers/xen/events/events_base.c  | 10 
 drivers/xen/platform-pci.c|  1 -
 drivers/xen/xenbus/xenbus.h   |  1 +
 drivers/xen/xenbus/xenbus_comms.c |  8 ---
 drivers/xen/xenbus/xenbus_probe.c | 81 +--
 include/xen/xenbus.h  |  2 +-
 7 files changed, 70 insertions(+), 35 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 60e901cd0de6..5a957a9a0984 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -371,7 +371,7 @@ static int __init xen_guest_init(void)
}
gnttab_init();
if (!xen_initial_domain())
-   xenbus_probe(NULL);
+   xenbus_probe();
 
/*
 * Making sure board specific code will not set up ops for
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index a8030332a191..e850f79351cb 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2060,16 +2060,6 @@ static struct irq_chip xen_percpu_chip __read_mostly = {
.irq_ack= ack_dynirq,
 };
 
-int xen_set_callback_via(uint64_t via)
-{
-   struct xen_hvm_param a;
-   a.domid = DOMID_SELF;
-   a.index = HVM_PARAM_CALLBACK_IRQ;
-   a.value = via;
-   return HYPERVISOR_hvm_op(HVMOP_set_param, &a);
-}
-EXPORT_SYMBOL_GPL(xen_set_callback_via);
-
 #ifdef CONFIG_XEN_PVHVM
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index dd911e1ff782..9db557b76511 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -149,7 +149,6 @@ static int platform_pci_probe(struct pci_dev *pdev,
ret = gnttab_init();
if (ret)
goto grant_out;
-   xenbus_probe(NULL);
return 0;
 grant_out:
gnttab_free_auto_xlat_frames();
diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 2a93b7c9c159..dc1537335414 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -115,6 +115,7 @@ int xenbus_probe_node(struct xen_bus_type *bus,
  const char *type,
  const char *nodename);
 int xenbus_probe_devices(struct xen_bus_type *bus);
+void xenbus_probe(void);
 
 void xenbus_dev_changed(const char *node, struct xen_bus_type *bus);
 
diff --git a/drivers/xen/xenbus/xenbus_comms.c 
b/drivers/xen/xenbus/xenbus_comms.c
index eb5151fc8efa..e5fda0256feb 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -57,16 +57,8 @@ DEFINE_MUTEX(xs_response_mutex);
 static int xenbus_irq;
 static struct task_struct *xenbus_task;
 
-static DECLARE_WORK(probe_work, xenbus_probe);
-
-
 static irqreturn_t wake_waiting(int irq, void *unused)
 {
-   if (unlikely(xenstored_ready == 0)) {
-   xenstored_ready = 1;
-   schedule_work(&probe_work);
-   }
-
wake_up(&xb_waitq);
return IRQ_HANDLED;
 }
diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index 44634d970a5c..c8f0282bb649 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -683,29 +683,76 @@ void unregister_xenstore_notifier(struct notifier_block 
*nb)
 }
 EXPORT_SYMBOL_GPL(unregister_xenstore_notifier);
 
-void xenbus_probe(struct work_struct *unused)
+void xenbus_probe(void)
 {
xenstored_ready = 1;
 
+   /*
+* In the HVM case, xenbus_init() deferred its call to
+* xs_init() in case callbacks were not operational yet.
+* So do it now.
+*/
+   if (xen_store_domain_type == XS_HVM)
+   xs_init();
+
/* Notify 

[PATCH v4 0/5] Xen INTX/GSI event channel delivery fixes

[David Woodhouse]

Fix various breakages with INTX/GSI event channel interrupt delivery,
and add a command line option to test it so that it hopefully doesn't
get so broken again.

Karim attempted to rip this out in 2017 but put it back because it's still
necessary with older versions of Xen. This fixes it properly, and makes it
easier to test. cf. https://lkml.org/lkml/2017/4/10/266

v2:
 • Add no_vector_callback to Documentation/admin-guide/kernel-parameters.txt
 • Further fixes to conditional smp_ops initialisation in xen_hvm_smp_init()

v3:
 • Rename test option to xen_no_vector_callback

v4:
 • Fix unconditional references to xen_have_vector_callback in Arm build

David Woodhouse (5):
  xen: Fix event channel callback via INTX/GSI
  xen: Set platform PCI device INTX affinity to CPU0
  x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery
  x86/xen: Don't register Xen IPIs when they aren't going to be used
  x86/xen: Fix xen_hvm_smp_init() when vector callback not available

 Documentation/admin-guide/kernel-parameters.txt |  4 ++
 arch/arm/xen/enlighten.c|  2 +-
 arch/x86/xen/enlighten_hvm.c| 15 -
 arch/x86/xen/smp_hvm.c  | 27 ++---
 drivers/xen/events/events_base.c| 10 ---
 drivers/xen/platform-pci.c  |  8 ++-
 drivers/xen/xenbus/xenbus.h |  1 +
 drivers/xen/xenbus/xenbus_comms.c   |  8 ---
 drivers/xen/xenbus/xenbus_probe.c   | 81 -
 include/xen/xenbus.h|  2 +-
 10 files changed, 110 insertions(+), 48 deletions(-)

Re: [PATCH 3/3] tools: Move memshrtool from tests/ to misc/

[Ian Jackson]

Andrew Cooper writes ("Re: [PATCH 3/3] tools: Move memshrtool from tests/ to 
misc/"):
> On 13/01/2021 13:01, Ian Jackson wrote:
> > Andrew Cooper writes ("[PATCH 3/3] tools: Move memshrtool from tests/ to 
> > misc/"):
> >> memshrtool is a tool for a human to use, rather than a test.  Move it into
> >> misc/ as a more appropriate location to live.  Also rename it to
> >> xen-memshare-tool
> > Acked-by: Ian Jackson 
> 
> Thanks, but I expect that Gitlab will tell me that I broke the ARM
> build, by losing a "only build this for x86"-ism.
> 
> I've folded this delta in to resolve:

Ooops.  Thanks.

Ian.

[qemu-mainline test] 158396: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
 test-amd64-amd64-xl-qcow2   21 guest-start/debian.repeat fail REGR. vs. 152631
 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 152631

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 152631
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 152631
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631
 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-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   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-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 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-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-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-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-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass

version targeted for testing:
 qemuuf8e1d8852e393b3fd524fb005e38590063d99bc0
baseline version:
 qemuu1d806cef0e38b5db8347a8e12f214d543204a314

Last test of basis   152631  2020-08-20 09:07:46 Z  146 days
Failing since152659  2020-08-21 14:07:39 Z  144 days  300 attempts
Testing same since   158396  2021-01-13 04:01:49 Z0 days1 attempts


344 people touched revisions under test,
not listing them all

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

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Nicolas Saenz Julienne]

Hi All,

On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
> On 1/5/21 7:41 PM, Claire Chang wrote:
> > Add the initialization function to create restricted DMA pools from
> > matching reserved-memory nodes in the device tree.
> > 
> > Signed-off-by: Claire Chang 
> > ---
> >  include/linux/device.h  |   4 ++
> >  include/linux/swiotlb.h |   7 +-
> >  kernel/dma/Kconfig  |   1 +
> >  kernel/dma/swiotlb.c| 144 ++--
> >  4 files changed, 131 insertions(+), 25 deletions(-)
> > 
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 89bb8b84173e..ca6f71ec8871 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -413,6 +413,7 @@ struct dev_links_info {
> >   * @dma_pools: Dma pools (if dma'ble device).
> >   * @dma_mem:   Internal for coherent mem override.
> >   * @cma_area:  Contiguous memory area for dma allocations
> > + * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
> >   * @archdata:  For arch-specific additions.
> >   * @of_node:   Associated device tree node.
> >   * @fwnode:Associated device node supplied by platform firmware.
> > @@ -515,6 +516,9 @@ struct device {
> >  #ifdef CONFIG_DMA_CMA
> >     struct cma *cma_area;   /* contiguous memory area for dma
> >    allocations */
> > +#endif
> > +#ifdef CONFIG_SWIOTLB
> > +   struct io_tlb_mem   *dma_io_tlb_mem;
> >  #endif
> >     /* arch specific additions */
> >     struct dev_archdata archdata;
> > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> > index dd8eb57cbb8f..a1bbd775 100644
> > --- a/include/linux/swiotlb.h
> > +++ b/include/linux/swiotlb.h
> > @@ -76,12 +76,13 @@ extern enum swiotlb_force swiotlb_force;
> >   *
> >   * @start: The start address of the swiotlb memory pool. Used to do a quick
> >   * range check to see if the memory was in fact allocated by this
> > - * API.
> > + * API. For restricted DMA pool, this is device tree adjustable.
> 
> Maybe write it as this is "firmware adjustable" such that when/if ACPI
> needs something like this, the description does not need updating.
> 
> [snip]
> 
> > +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> > +   struct device *dev)
> > +{
> > +   struct io_tlb_mem *mem = rmem->priv;
> > +   int ret;
> > +
> > +   if (dev->dma_io_tlb_mem)
> > +   return -EBUSY;
> > +
> > +   if (!mem) {
> > +   mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> > +   if (!mem)
> > +   return -ENOMEM;
> > +
> > +   if (!memremap(rmem->base, rmem->size, MEMREMAP_WB)) {
> 
> MEMREMAP_WB sounds appropriate as a default.

As per the binding 'no-map' has to be disabled here. So AFAIU, this memory will
be part of the linear mapping. Is this really needed then?

> Documentation/devicetree/bindings/reserved-memory/ramoops.txt does
> define an "unbuffered" property which in premise could be applied to the
> generic reserved memory binding as well and that we may have to be
> honoring here, if we were to make it more generic. Oh well, this does
> not need to be addressed right now I guess.





signature.asc
Description: This is a digitally signed message part

Re: [PATCH 2/6] x86/mm: p2m_add_foreign() is HVM-only

[Oleksandr]

On 12.01.21 13:58, Jan Beulich wrote:

Hi Jan.


On 11.01.2021 09:23, Oleksandr wrote:

On 11.01.21 09:41, Jan Beulich wrote:

If you could also provide your exact .config, I could see whether I
can repro here with some of the gcc5 versions I have laying around.

Please see attached

Builds perfectly fine with 5.4.0 here.


Thank you for testing.


I wonder whether I indeed missed something. I have switched to 5.4.0 
again (from 9.3.0) and rechecked, a build issue was still present.
I even downloaded 5.4.0 sources and built them to try to build Xen, and 
got the same effect.  What I noticed is that for non-debug builds the 
build issue wasn't present.
Then I decided to build today's staging 
(414be7b66349e7dca42bc1fd47c2b2f5b2d27432 xen/memory: Fix compat 
XENMEM_acquire_resource for size requests) instead of 9-day's old one when
I had initially reported about that build issue 
(7ba2ab495be54f608cb47440e1497b2795bd301a x86/p2m: Fix 
paging_gva_to_gfn() for nested virt). Today's staging builds perfectly 
fine with 5.4.0.
It seems that commit in the middle 
(994f6478a48a60e3b407c7defc2d36a80f880b04 xsm/dummy: harden against 
speculative abuse) indirectly fixes that weird build issue with 5.4.0...



--
Regards,

Oleksandr Tyshchenko

Re: [PATCH v4 0/5] Xen INTX/GSI event channel delivery fixes

[Jürgen Groß]

On 13.01.21 14:26, David Woodhouse wrote:

Fix various breakages with INTX/GSI event channel interrupt delivery,
and add a command line option to test it so that it hopefully doesn't
get so broken again.

Karim attempted to rip this out in 2017 but put it back because it's still
necessary with older versions of Xen. This fixes it properly, and makes it
easier to test. cf. https://lkml.org/lkml/2017/4/10/266

v2:
  • Add no_vector_callback to Documentation/admin-guide/kernel-parameters.txt
  • Further fixes to conditional smp_ops initialisation in xen_hvm_smp_init()

v3:
  • Rename test option to xen_no_vector_callback

v4:
  • Fix unconditional references to xen_have_vector_callback in Arm build

David Woodhouse (5):
   xen: Fix event channel callback via INTX/GSI
   xen: Set platform PCI device INTX affinity to CPU0
   x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery
   x86/xen: Don't register Xen IPIs when they aren't going to be used
   x86/xen: Fix xen_hvm_smp_init() when vector callback not available

  Documentation/admin-guide/kernel-parameters.txt |  4 ++
  arch/arm/xen/enlighten.c|  2 +-
  arch/x86/xen/enlighten_hvm.c| 15 -
  arch/x86/xen/smp_hvm.c  | 27 ++---
  drivers/xen/events/events_base.c| 10 ---
  drivers/xen/platform-pci.c  |  8 ++-
  drivers/xen/xenbus/xenbus.h |  1 +
  drivers/xen/xenbus/xenbus_comms.c   |  8 ---
  drivers/xen/xenbus/xenbus_probe.c   | 81 -
  include/xen/xenbus.h|  2 +-
  10 files changed, 110 insertions(+), 48 deletions(-)


Series pushed to xen/tip.git for-linus-5.11


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

PCI passthrough regression on BSD* guests since 4.13.1

[Samuel Verschelde]

Hi list.

XCP-ng users have reported a regression with PCI passthrough in XCP-ng 
8.2. We're using Xen 4.13.1 + patches (like Citrix Hypervisor 8.2 does) 
[1].


Symptoms: after a shutdown or reboot of the VM, the passed-through 
device can't be passed-through anymore.


We've build various versions of Xen with select reverted commits for 
users to test, and they helped us identify commit 
6a1036e28240217d1dbfcb096800313a468cdb0e [2] as what caused it.


On IRC, royger confirmed having reproduced the issue.

Best regards,

Samuel Verschelde

[1] 
https://xcp-ng.org/forum/topic/4001/passthough-on-8-2-hangs-on-vm-reboot-and-stops-other-vms-passthough-devices-working 

[2] 
https://github.com/xen-project/xen/commit/6a1036e28240217d1dbfcb096800313a468cdb0e

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Robin Murphy]

On 2021-01-13 13:59, Nicolas Saenz Julienne wrote:

Hi All,

On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:

On 1/5/21 7:41 PM, Claire Chang wrote:

Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes in the device tree.

Signed-off-by: Claire Chang 
---
  include/linux/device.h  |   4 ++
  include/linux/swiotlb.h |   7 +-
  kernel/dma/Kconfig  |   1 +
  kernel/dma/swiotlb.c| 144 ++--
  4 files changed, 131 insertions(+), 25 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 89bb8b84173e..ca6f71ec8871 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -413,6 +413,7 @@ struct dev_links_info {
   * @dma_pools:Dma pools (if dma'ble device).
   * @dma_mem:  Internal for coherent mem override.
   * @cma_area: Contiguous memory area for dma allocations
+ * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
   * @archdata: For arch-specific additions.
   * @of_node:  Associated device tree node.
   * @fwnode:   Associated device node supplied by platform firmware.
@@ -515,6 +516,9 @@ struct device {
  #ifdef CONFIG_DMA_CMA
    struct cma *cma_area;   /* contiguous memory area for dma
   allocations */
+#endif
+#ifdef CONFIG_SWIOTLB
+   struct io_tlb_mem   *dma_io_tlb_mem;
  #endif
    /* arch specific additions */
    struct dev_archdata archdata;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index dd8eb57cbb8f..a1bbd775 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -76,12 +76,13 @@ extern enum swiotlb_force swiotlb_force;
   *
   * @start:The start address of the swiotlb memory pool. Used to do a quick
   *range check to see if the memory was in fact allocated by this
- * API.
+ * API. For restricted DMA pool, this is device tree adjustable.


Maybe write it as this is "firmware adjustable" such that when/if ACPI
needs something like this, the description does not need updating.


TBH I really don't think this needs calling out at all. Even in the 
regular case, the details of exactly how and where the pool is allocated 
are beyond the scope of this code - architectures already have several 
ways to control that and make their own decisions.




[snip]


+static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
+   struct device *dev)
+{
+   struct io_tlb_mem *mem = rmem->priv;
+   int ret;
+
+   if (dev->dma_io_tlb_mem)
+   return -EBUSY;
+
+   if (!mem) {
+   mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+   if (!mem)
+   return -ENOMEM;
+
+   if (!memremap(rmem->base, rmem->size, MEMREMAP_WB)) {


MEMREMAP_WB sounds appropriate as a default.


As per the binding 'no-map' has to be disabled here. So AFAIU, this memory will
be part of the linear mapping. Is this really needed then?


More than that, I'd assume that we *have* to use the linear/direct map 
address rather than anything that has any possibility of being a vmalloc 
remap, otherwise we can no longer safely rely on 
phys_to_dma/dma_to_phys, no?


That said, given that we're not actually using the returned address, I'm 
not entirely sure what the point of this call is anyway. If we can 
assume it's always going to return the linear map address via 
try_ram_remap() then we can equally just go ahead and use the linear map 
address straight away. I don't really see how we could ever hit the 
"is_ram == REGION_MIXED" case in memremap() that would return NULL, if 
we passed the memblock check earlier in __reserved_mem_alloc_size() such 
that this rmem node ever got to be initialised at all.


Robin.


Documentation/devicetree/bindings/reserved-memory/ramoops.txt does
define an "unbuffered" property which in premise could be applied to the
generic reserved memory binding as well and that we may have to be
honoring here, if we were to make it more generic. Oh well, this does
not need to be addressed right now I guess.

Re: Proposal - lightweight auto test binaries

[Andrew Cooper]

On 12/01/2021 17:35, Ian Jackson wrote:
> Andy and I were discussing some new tests he's written which (will)
> live in xen.git and which we would like to wire into osstest.
>
> We came up with the following proposal (I have refined some of the
> details beyond what we discussed on IRC):
>
>  * Tests will live in tools/tests/ ideally, but they might
>live in other places in the xen.git source tree.

I've submitted
https://lore.kernel.org/xen-devel/20210113123455.23209-1-andrew.coop...@citrix.com/T/#u
to clean up the not-really-tests from the tests dir.

This leaves us with cpu-policy, depriv, mce-test, vhpet, vpci,
x86_emulator and xenstore.

Of those, cpu-policy, vpci and x86_emulator are real unit tests,
involving varying quantities of gymnastics to compile.  They can in
principle be run on the build machine, but x86_emulator is sensitive to
the CPU instructions available, and would definitely benefit from
running on as wider set of hardware as possible.

vhpet is also a real unit test, but isn't even compiled by default and
seems to need some manual code hacking to compile, and takes a
complicated array command line arguments.

xenstore needs a running xenstored to talk to, so needs to run on the
test system, but is otherwise self contained and easy to use.

depriv, I'm struggling to follow.  Its presumably doing things with the
various ioctl restriction, therefore wants to be on the test system, but
does take a complicated array of command line options.

mce-test is a complicated mess of test case scripts, which look like
they might have been pulled out of a preexisting test framework
elsewhere.  The binary xen-mceinj uses the MCE interposer functionality
to try and inject real-looking errors into the system.  I haven't had
much luck with this in the past, and it has been bitrotting for most of
a decade.  I don't know if there is anything salvageable here or not.


I've had a quick look through the rest of the tree and I can't spot
anything else which is obviously test code.


I reckon for a first stab, trying to convert xenstore and cpu-policy to
the "simple" API would be a good start.  They both have trivial build
requirements, and would be trivial to convert to an exit code based
protocol, which would get us content to run for both x86 and ARM in OSSTest.

CC Juergen, who is the owner of the xenstore test.  Are you happy with
this being tweaked in the hope that it gets run automatically by OSSTest?

The rest of the tests are going to be varying quantities of complicated
to convert.

>  * When appropriately configured, the xen.git build system
>will ship them into dist/install/usr/local/
>
>  * There will be a specific directory containing tests which
>are suitable for running automatically:
>   dist/install/usr/local/lib/xen/autotests
>
>  * The pass/success reporting API will be encoded into the
>filename.  For now we define only one API:
>  dist/install/usr/local/lib/xen/autotests/simple/*

Whatever we go for, it ought to be an easy path, and honestly - that's a
mouthful to get to.  These tests need to be just as easy for developers
to use.

How about opt/xen-autotest/* ?  Much easier in a deb/rpm build to filter
the things which clearly shouldn't be in a production system.  It's also
invariant of libdir which is an advantage for downstreams who test on
more than one distro.

I certainly have plans to reuse this infrastructure in XenRT.  I expect
other downstreams would as well.

> The "simple" test API is as follows:
>
>  * Every executable file (or symlink to one) in
>  dist/install/usr/local/lib/xen/autotests/simple/
>will be run with no arguments.
>
>  * Only files whose names contain only [-0-9a-z] will be run.
>Others will be ignored.  NB _ is not allowed.

I'm happy not using _, but why the restriction?

>  * A test may exit with one of the XTF exit statuses:
>   0 # XTF SUCCESS
>   3 # XTF SKIP
>   4 # XTF ERROR
>   5 # XTF FAILURE
>   6 # XTF CRASH
>(osstest will treat anything other than 0 and 3 as "fail")
>Any other termination should be treated as CRASH.
>
>  * If a test exits nonzero it should print some information about
>the situation to stderr.
>
>  * Tests may print other information to stderr, which will be captured
>and logged.
>
>  * Tests *must not* print anything to stdout.  Test runners *must*
>ignore stdout (though they may log it, possibly mixed in with
>stderr).  stdout is reserved for future extension.

I disagree.  It is far more important that the tests are pleasant for
humans to use, both in terms of developing them to begin with, and
maintaining them if they go wrong.

In practice, this means human-useful stuff on stdout.  The test
automation does not need to care - all it should do is log
stdout/stderr, and act upon the exit code.  (Perhaps this is what you
meant, but its not clear IMO.)


>  * Tests should exit with XTF ERROR if they are passed any arguments.

./

Re: Inconsistent console behavior during HVM direct boot

[Tamas K Lengyel]

On Wed, Jan 13, 2021 at 8:18 AM Roger Pau Monné  wrote:
>
> On Tue, Jan 12, 2021 at 09:54:18PM -0500, Tamas K Lengyel wrote:
> > While direct booting a Linux kernel into an HVM VM no console output
> > is received if serial="pty" is set in the VM config but the kernel
> > command line specifies "console=hvc0". If "console=ttyS0" is specified
> > then the console output is received as expected. Conversely, if the
> > serial line is commented out in the VM config but hvc0 is set on the
> > kernel command line then it also works. It's unclear whether this
> > behavior is expected or not, after some discussion it sounds like all
> > kernels ought to understand hvc0 irrespective of the serial="pty" line
> > being set or not. Reporting this in case someone has more insight
> > and/or inclination digging into this.
>
> So I think this is (as confusing as it might seem) the intended
> behavior.
>
> Using serial='pty' exposes an emulated serial device to the guest and
> 'xl console' will fetch the output from that device by default. So on
> the Linux kernel command line you need to use console=ttyS0 in order
> to point Linux to use the emulated serial device.
>
> however if serial='pty' is not used, there will be no emulated serial
> device exposed to the guest, only the PV console, and that's what 'xl
> console' will attach to in that case. You then need to point the Linux
> kernel to use the PV serial console, by adding the console=hvc0
> command line.
>
> I'm unsure how to clarify this, maybe some additions could be made to
> the xl.cfg man page to note that using serial='pty' will add an
> emulated serial device to the guest, and that by default 'xl console'
> will fetch the output from that device instead of the paravirtualized
> console?

Hi Roger,
that explanation makes sense, I wasn't aware that there would be two
different console's available to the guest if serial="pty" is set and
that xl would pick on over the other. So adding that to the
documentation would be helpful. Perhaps also pointing out under what
scenario is the emulated console vs the pv console is useful. I assume
the point of the emulated console would be to get console output from
software that's not Xen-aware (like GRUB)?

Thanks,
Tamas

Re: [PATCH] x86/dpci: remove the dpci EOI timer

[Jason Andryuk]

On Wed, Jan 13, 2021 at 8:11 AM Roger Pau Monné  wrote:
>
> On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne 
> > > Sent: Wednesday, January 13, 2021 1:33 AM
> > >
> > > Current interrupt pass though code will setup a timer for each
> > > interrupt injected to the guest that requires an EOI from the guest.
> > > Such timer would perform two actions if the guest doesn't EOI the
> > > interrupt before a given period of time. The first one is deasserting
> > > the virtual line, the second is perform an EOI of the physical
> > > interrupt source if it requires such.
> > >
> > > The deasserting of the guest virtual line is wrong, since it messes
> > > with the interrupt status of the guest. It's not clear why this was
> > > odne in the first place, it should be the guest the one to EOI the
> > > interrupt and thus deassert the line.
> > >
> > > Performing an EOI of the physical interrupt source is redundant, since
> > > there's already a timer that takes care of this for all interrupts,
> > > not just the HVM dpci ones, see irq_guest_action_t struct eoi_timer
> > > field.
> > >
> > > Since both of the actions performed by the dpci timer are not
> > > required, remove it altogether.
> > >
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > > As with previous patches, I'm having a hard time figuring out why this
> > > was required in the first place. I see no reason for Xen to be
> > > deasserting the guest virtual line. There's a comment:
> > >
> > > /*
> > >  * Set a timer to see if the guest can finish the interrupt or not. For
> > >  * example, the guest OS may unmask the PIC during boot, before the
> > >  * guest driver is loaded. hvm_pci_intx_assert() may succeed, but the
> > >  * guest will never deal with the irq, then the physical interrupt line
> > >  * will never be deasserted.
> > >  */
> > >
> > > Did this happen because the device was passed through in a bogus state
> > > where it would generate interrupts without the guest requesting
> >
> > It could be a case where two devices share the same interrupt line and
> > are assigned to different domains. In this case, the interrupt activity of
> > two devices interfere with each other.
>
> This would also seem to be problematic if the device decides to use
> MSI instead of INTx, but due to the shared nature of the INTx line we
> would continue to inject INTx (generated from another device not
> passed through to the guest) to the guest even if the device has
> switched to MSI.
>
> > >
> > > Won't the guest face the same issues when booted on bare metal, and
> > > thus would already have the means to deal with such issues?
> >
> > The original commit was added by me in ~13yrs ago (0f843ba00c95)
> > when enabling Xen in a client virtualization environment where interrupt
> > sharing is popular.
>
> Thanks, the reference to the above commit is helpful, I wasn't able to
> find it and it contains a comment that I think has been lost, which
> provides the background on why this was added.
>
> > I believe above comment was recorded for a real
> > problem at the moment (deassert resets the intx line to unblock further
> > interrupts). But I'm not sure whether it is still the case after both Xen 
> > and
> > guest OS have changed a lot. At least some test from people who
> > still use Xen in shared interrupt scenario would be helpful. Or, if such
> > usage is already niche, maybe we can consider disallow passing through
> > devices which share the same interrupt line to different domains and
> > then safely remove this dpci EOI trick.
>
> So the deassert done by timeout only deasserts the virtual line, but
> doesn't for example clear the IRR bit from the vIO-APIC pin, which
> will cause further interrupts to not be delivered anyway until a
> proper EOI (or a switch to trigger mode) is done to the pin.
>
> I think it's going to be complicated for me to find a system that has
> two devices I can passthrough sharing the same GSI.

I have some laptops running OpenXT where the USB controller and NIC
share an interrupt, and I assign them to different domains.  Qubes
would hit this as well.

(I hoped MSI translate would help me sidestep the need to XSM label
the shared PIRQ, but as the other thread mentions, qemu-upstream
doesn't support that.  I started using this instead:
https://lore.kernel.org/xen-devel/20201019200318.103781-1-jandr...@gmail.com/)

Regards,
Jason

Re: Proposal - lightweight auto test binaries

[Jürgen Groß]

On 13.01.21 16:45, Andrew Cooper wrote:

I reckon for a first stab, trying to convert xenstore and cpu-policy to
the "simple" API would be a good start.  They both have trivial build
requirements, and would be trivial to convert to an exit code based
protocol, which would get us content to run for both x86 and ARM in OSSTest.

CC Juergen, who is the owner of the xenstore test.  Are you happy with
this being tweaked in the hope that it gets run automatically by OSSTest?


Sure!

I've written those tests for validating my rework of the C-xenstored
transaction handling, but including them in OSSTest is much appreciated.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v10 06/25] tools/xenstore: add live update command to xenstore-control

[Jürgen Groß]

On 06.01.21 15:42, Edwin Torok wrote:

On Tue, 2020-12-15 at 17:35 +0100, Juergen Gross wrote:


[...]
+static int live_update_start(struct xs_handle *xsh, bool force,
unsigned int to)
+{
+    int len = 0;
+    char *buf = NULL, *ret;
+    time_t time_start;
+
+    if (asprintf(&ret, "%u", to) < 0)
+    return 1;
+    len = add_to_buf(&buf, "-s", len);
+    len = add_to_buf(&buf, "-t", len);
+    len = add_to_buf(&buf, ret, len);
+    free(ret);
+    if (force)
+    len = add_to_buf(&buf, "-F", len);
+    if (len < 0)
+    return 1;
+
+    for (time_start = time(NULL); time(NULL) - time_start < to;) {
+    ret = xs_control_command(xsh, "live-update", buf, len);
+    if (!ret)
+    goto err;
+    if (strcmp(ret, "BUSY"))
+    break;
+    }


We've discovered issues with this during testing: when a live-update is
not possible (e.g. guest with active transaction held open on purpose)
xenstored gets flooded with live-update requests until the timeout is
reached.

This is problematic for multiple reasons:
* flooding xenstored reduces its throughput, and makes it use 100% CPU.
Depending on the implementation and configuration it may also flood the
logs (which isn't fatal, the system still stays alive if you ENOSPC on
/var/log, but it makes it difficult to debug issues if a live update
gets you to ENOSPC as you may not see actual failures from after the
live update).
* flooding xenstored causes the evtchn to overflow and AFAICT neither
xenstored or oxenstored is capable of coping with that (oxenstored
infinite loops when that happens). IIUC this needs to be fixed in the
kernel, so it doesn't return EFBIG in the first place. As a workaround
I added a sleep(1) in this loop
* the timeout is hit on both client and server sides, but depending on
rounding almost always happens on the client side first which prevents
us from displaying a more informative error message from the server. As
a workaround I increased the client side timeout by 2s to cope with
rounding and give the server a chance to reply. Oxenstored can reply
with a list of domains preventing the live-update for example.

My workarounds looked like this:
@@ -42,6 +43,9 @@ static int live_update_start(struct xs_handle *xsh,
bool force, unsigned int to)
  len = add_to_buf(&buf, "-F", len);
  if (len < 0)
  return 1;
+/* +1 for rounding issues
+ * +1 to give oxenstored a chance to timeout and report back first
*/
+to += 2;
  
  for (time_start = time(NULL); time(NULL) - time_start < to;) {

  ret = xs_control_command(xsh, "live-update", buf, len);
@@ -49,6 +53,12 @@ static int live_update_start(struct xs_handle *xsh,
bool force, unsigned int to)
  goto err;
  if (strcmp(ret, "BUSY"))
  break;
+/* TODO: use task ID for commands, avoid busy loop polling
here
+ * oxenstored checks BUSY condition internally on every main
loop iteration anyway.
+ * Avoid flooding xenstored with live-update requests.
+ * The flooding can also cause the evtchn to overflow in
xenstored which makes
+ * xenstored enter an infinite loop */
+sleep(1);
  }

This also required various heuristics in oxenstored to differentiate
between a new live-update command and querying the status of an already
completed live-update command, otherwise I almost always ended up doing
2 live-updates in a row (first one queued up, returned BUSY, completed
after a while, and then another one from all the repeated live-update
requests).

I'd prefer it if there was a more asynchronous protocol available for
live-update:
* the live-update on its own queues up the live update request and
returns a generation ID. xenstored retries on its own during each of
its main loop iterations whether the conditions for live-update are now
met
* when a generation ID is specified with the live-update command it
acts as a query to return the status. A query for generation ID <
current ID return success, and for generation ID = current ID it
returns either BUSY, or a specific error if known (e.g. timeout reached
and list of domains preventing live update)
* the generation ID gets incremented every time a live update succeeds
  
This would eliminiate the need for a client-side timeout, since each of

these commands would be non-blocking.
It'd also avoid the busy-poll flood.

Obviously any change here has to be backwards compatible with the
already deployed xenstored and oxenstored which doesn't know about
generation IDs, but you can tell them apart based on the reply: if you
get back OK/BUSY/some error it is the old version, if you get back a
generation ID it is the new version.

I ran out of time to implement this before the embargo was up, should I
go ahead with prototyping a patch for this now, or do you see an
alternative way to make the live-update command more robust?


I think this can be made much easier:

The live-update should be handled completely in the 

[PATCH v2 0/7] Rid W=1 warnings in Ethernet

[Lee Jones]

Resending the stragglers again. 
 

This set is part of a larger effort attempting to clean-up W=1  
 
kernel builds, which are currently overwhelmingly riddled with  
 
niggly little warnings. 
 

 
v2: 
 
 - Squashed IBM patches 
 
 - Fixed real issue in SMSC
 - Added Andrew's Reviewed-by tags on remainder

Lee Jones (7):
  net: ethernet: smsc: smc91x: Fix function name in kernel-doc header
  net: xen-netback: xenbus: Demote nonconformant kernel-doc headers
  net: ethernet: ti: am65-cpsw-qos: Demote non-conformant function
header
  net: ethernet: ti: am65-cpts: Document am65_cpts_rx_enable()'s 'en'
parameter
  net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
  net: ethernet: toshiba: ps3_gelic_net: Fix some kernel-doc
misdemeanours
  net: ethernet: toshiba: spider_net: Document a whole bunch of function
parameters

 drivers/net/ethernet/ibm/ibmvnic.c   | 27 ++--
 drivers/net/ethernet/smsc/smc91x.c   |  2 +-
 drivers/net/ethernet/ti/am65-cpsw-qos.c  |  2 +-
 drivers/net/ethernet/ti/am65-cpts.c  |  2 +-
 drivers/net/ethernet/toshiba/ps3_gelic_net.c |  8 +++---
 drivers/net/ethernet/toshiba/spider_net.c| 18 -
 drivers/net/xen-netback/xenbus.c |  4 +--
 drivers/net/xen-netfront.c   |  6 ++---
 8 files changed, 37 insertions(+), 32 deletions(-)

Cc: Alexei Starovoitov 
Cc: Benjamin Herrenschmidt 
Cc: b...@vger.kernel.org
Cc: Daniel Borkmann 
Cc: Dany Madden 
Cc: Daris A Nevil 
Cc: "David S. Miller" 
Cc: Erik Stahlman 
Cc: Geoff Levand 
Cc: Grygorii Strashko 
Cc: "Gustavo A. R. Silva" 
Cc: Ishizaki Kou 
Cc: Ivan Khoronzhuk 
Cc: Jakub Kicinski 
Cc: Jens Osterkamp 
Cc: Jesper Dangaard Brouer 
Cc: John Allen 
Cc: John Fastabend 
Cc: Kurt Kanzenbach 
Cc: Lijun Pan 
Cc: linuxppc-...@lists.ozlabs.org
Cc: Michael Ellerman 
Cc: net...@vger.kernel.org
Cc: Nicolas Pitre 
Cc: Paul Durrant 
Cc: Paul Mackerras 
Cc: Peter Cammaert 
Cc: Russell King 
Cc: Rusty Russell 
Cc: Santiago Leon 
Cc: Sukadev Bhattiprolu 
Cc: Thomas Falcon 
Cc: Utz Bacher 
Cc: Wei Liu 
Cc: xen-devel@lists.xenproject.org
-- 
2.25.1

[PATCH 2/7] net: xen-netback: xenbus: Demote nonconformant kernel-doc headers

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member 
'dev' not described in 'frontend_changed'
 drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member 
'frontend_state' not described in 'frontend_changed'
 drivers/net/xen-netback/xenbus.c:1001: warning: Function parameter or member 
'dev' not described in 'netback_probe'
 drivers/net/xen-netback/xenbus.c:1001: warning: Function parameter or member 
'id' not described in 'netback_probe'

Cc: Wei Liu 
Cc: Paul Durrant 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Jesper Dangaard Brouer 
Cc: John Fastabend 
Cc: Rusty Russell 
Cc: xen-devel@lists.xenproject.org
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
Reviewed-by: Andrew Lunn 
Signed-off-by: Lee Jones 
---
 drivers/net/xen-netback/xenbus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 6f10e0998f1ce..a5439c130130f 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -411,7 +411,7 @@ static void read_xenbus_frontend_xdp(struct backend_info 
*be,
vif->xdp_headroom = headroom;
 }
 
-/**
+/*
  * Callback received when the frontend's state changes.
  */
 static void frontend_changed(struct xenbus_device *dev,
@@ -996,7 +996,7 @@ static int netback_remove(struct xenbus_device *dev)
return 0;
 }
 
-/**
+/*
  * Entry point to this code when a new device is created.  Allocate the basic
  * structures and switch to InitWait.
  */
-- 
2.25.1

Re: Proposal - lightweight auto test binaries

[Ian Jackson]

Andrew Cooper writes ("Re: Proposal - lightweight auto test binaries"):
> I've submitted
> https://lore.kernel.org/xen-devel/20210113123455.23209-1-andrew.coop...@citrix.com/T/#u
> to clean up the not-really-tests from the tests dir.

Yay.

> This leaves us with cpu-policy, depriv, mce-test, vhpet, vpci,
> x86_emulator and xenstore.
> 
> Of those, cpu-policy, vpci and x86_emulator are real unit tests,
> involving varying quantities of gymnastics to compile.  They can in
> principle be run on the build machine, but x86_emulator is sensitive to
> the CPU instructions available, and would definitely benefit from
> running on as wider set of hardware as possible.
> 
> vhpet is also a real unit test, but isn't even compiled by default and
> seems to need some manual code hacking to compile, and takes a
> complicated array command line arguments.
> 
> xenstore needs a running xenstored to talk to, so needs to run on the
> test system, but is otherwise self contained and easy to use.
> 
> depriv, I'm struggling to follow.  Its presumably doing things with the
> various ioctl restriction, therefore wants to be on the test system, but
> does take a complicated array of command line options.

This is already used by osstest in its qemu depriv tests.  It has a
complicated bespoke calling convention.  It think it should not be
disturbed as part of this current work.

> I reckon for a first stab, trying to convert xenstore and cpu-policy to
> the "simple" API would be a good start.  They both have trivial build
> requirements, and would be trivial to convert to an exit code based
> protocol, which would get us content to run for both x86 and ARM in OSSTest.

SGTM

Right, on to your review of my draft.  Thanks for the detailed
attention.

> >  * When appropriately configured, the xen.git build system
> >will ship them into dist/install/usr/local/
> >
> >  * There will be a specific directory containing tests which
> >are suitable for running automatically:
> >   dist/install/usr/local/lib/xen/autotests
> >
> >  * The pass/success reporting API will be encoded into the
> >filename.  For now we define only one API:
> >  dist/install/usr/local/lib/xen/autotests/simple/*
> 
> Whatever we go for, it ought to be an easy path, and honestly - that's a
> mouthful to get to.  These tests need to be just as easy for developers
> to use.
> 
> How about opt/xen-autotest/* ?  Much easier in a deb/rpm build to filter
> the things which clearly shouldn't be in a production system.  It's also
> invariant of libdir which is an advantage for downstreams who test on
> more than one distro.

I don't have a strong opinion about the path in dist/.  I was
imagining that we would not build these by default, so there wasn't a
problem with clutter in distro packages.

I think that for future extensibility we will want to think about how
tests will find any pieces of data, helper executables, or thatever.
I would prefer to re-use the existing mechanisms for finding pieces of
the installation, even though that makes the result depend on libdir.

Also, that means these tests could be easily plumbed into things like
Debian's autopkgtest system.  That is a mechanism for testing
as-installed packages and a test support .deb is an easy thing to
instroduce there.

In summary, I would prefer to use our existing mechanisms for
controlling the location and installation of binaries, rather than
invent a new ad-hoc arrangement which will turn out to be
insufficient, get extended ad-hoc, and maybe eventually replaced by
the standard approach.

For human developers, I think it's fine to encourage them to run the
programs directly out of the build tree (copied to a target test host
if necessary) rather than an installed copy somewhere in /usr.  I do
that with xl stuff and similar all the time - rsyncing the tree to my
test box from the build box if they're not the same environent.

> I certainly have plans to reuse this infrastructure in XenRT.  I expect
> other downstreams would as well.
> 
> > The "simple" test API is as follows:
> >
> >  * Every executable file (or symlink to one) in
> >  dist/install/usr/local/lib/xen/autotests/simple/
> >will be run with no arguments.
> >
> >  * Only files whose names contain only [-0-9a-z] will be run.
> >Others will be ignored.  NB _ is not allowed.
> 
> I'm happy not using _, but why the restriction?

That leaves it possible to use _ for delimiters when test case names
are embedded in other strings within in a calling test case framework,
etc.  Cf the same restriction on Debian package names, which means
that a conventional .deb filename can be reliably broken into its
component parts.

Also making a rule for _ vs - makes the result more aesthetically
pleasing and also easier for humans who do not have to guess (or
remember) whether a particular test has _ or - (or even both!).  So we
should forbid exactly one of the two.

> >  * Tests *must not* print anything to stdout.  Test runners

Re: [PATCH v2] xen/arm: don't read aarch32 regs when aarch32 isn't available

[Julien Grall]

Hi Stefano,

I think you forgot to update the title to say the state is EL0.

On 12/01/2021 23:44, Stefano Stabellini wrote:

Don't read aarch32 system registers at boot time when the aarch32 state
is not available at EL0. They are UNKNOWN, so it is not useful to read
them.  Moreover, on Cavium ThunderX reading ID_PFR2_EL1 causes a Xen
crash.  Instead, only read them when aarch32 is available.

Leave the corresponding fields in struct cpuinfo_arm so that they
are read-as-zero from a guest.

Since we are editing identify_cpu, also fix the indentation: 4 spaces
instead of 8.

Fixes: 9cfdb489af81 ("xen/arm: Add ID registers and complete cpuinfo")
Link: 
https://lore.kernel.org/xen-devel/f90e40ee-b042-6cc5-a08d-aef41a279...@suse.com/
Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v10 06/25] tools/xenstore: add live update command to xenstore-control

[Edwin Torok]

On Wed, 2021-01-13 at 17:34 +0100, Jürgen Groß wrote:
> On 06.01.21 15:42, Edwin Torok wrote:
> > [...]
> > 
> > I'd prefer it if there was a more asynchronous protocol available
> > for
> > live-update:
> > * the live-update on its own queues up the live update request and
> > returns a generation ID. xenstored retries on its own during each
> > of
> > its main loop iterations whether the conditions for live-update are
> > now
> > met
> > * when a generation ID is specified with the live-update command it
> > acts as a query to return the status. A query for generation ID <
> > current ID return success, and for generation ID = current ID it
> > returns either BUSY, or a specific error if known (e.g. timeout
> > reached
> > and list of domains preventing live update)
> > * the generation ID gets incremented every time a live update
> > succeeds
> >   
> > This would eliminiate the need for a client-side timeout, since
> > each of
> > these commands would be non-blocking.
> > It'd also avoid the busy-poll flood.
> > 
> > Obviously any change here has to be backwards compatible with the
> > already deployed xenstored and oxenstored which doesn't know about
> > generation IDs, but you can tell them apart based on the reply: if
> > you
> > get back OK/BUSY/some error it is the old version, if you get back
> > a
> > generation ID it is the new version.
> > 
> > I ran out of time to implement this before the embargo was up,
> > should I
> > go ahead with prototyping a patch for this now, or do you see an
> > alternative way to make the live-update command more robust?
> 
> I think this can be made much easier:
> 
> The live-update should be handled completely in the daemon, so
> returning only with success or failure. Returning BUSY wouldn't
> occur this way, but either "OK" (after the successful LU) or a
> failure reason (e.g. list of domains blocking) would be
> returned.
> 
> I'll have a try with this approach.
> 
> 

In oxenstored each request wants an immediate reply, so delaying the
reply to after the live-update is not trivial.
Should be possible to do though (e.g. mark the socket such that no
further xenstore protocol is processed on it, and "put back" the live
update request, to be replied by the new xenstored after the live
update completes, which would clear the 'do not process this socket'
flag), I'll be curious to see what your approach will look like.

Best regards,
--Edwin

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Florian Fainelli]

On 1/13/21 7:27 AM, Robin Murphy wrote:
> On 2021-01-13 13:59, Nicolas Saenz Julienne wrote:
>> Hi All,
>>
>> On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
>>> On 1/5/21 7:41 PM, Claire Chang wrote:
 Add the initialization function to create restricted DMA pools from
 matching reserved-memory nodes in the device tree.

 Signed-off-by: Claire Chang 
 ---
   include/linux/device.h  |   4 ++
   include/linux/swiotlb.h |   7 +-
   kernel/dma/Kconfig  |   1 +
   kernel/dma/swiotlb.c    | 144
 ++--
   4 files changed, 131 insertions(+), 25 deletions(-)

 diff --git a/include/linux/device.h b/include/linux/device.h
 index 89bb8b84173e..ca6f71ec8871 100644
 --- a/include/linux/device.h
 +++ b/include/linux/device.h
 @@ -413,6 +413,7 @@ struct dev_links_info {
    * @dma_pools:    Dma pools (if dma'ble device).
    * @dma_mem:    Internal for coherent mem override.
    * @cma_area:    Contiguous memory area for dma allocations
 + * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
    * @archdata:    For arch-specific additions.
    * @of_node:    Associated device tree node.
    * @fwnode:    Associated device node supplied by platform firmware.
 @@ -515,6 +516,9 @@ struct device {
   #ifdef CONFIG_DMA_CMA
   struct cma *cma_area;    /* contiguous memory area for dma
  allocations */
 +#endif
 +#ifdef CONFIG_SWIOTLB
 +    struct io_tlb_mem    *dma_io_tlb_mem;
   #endif
   /* arch specific additions */
   struct dev_archdata    archdata;
 diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
 index dd8eb57cbb8f..a1bbd775 100644
 --- a/include/linux/swiotlb.h
 +++ b/include/linux/swiotlb.h
 @@ -76,12 +76,13 @@ extern enum swiotlb_force swiotlb_force;
    *
    * @start:    The start address of the swiotlb memory pool. Used
 to do a quick
    *    range check to see if the memory was in fact allocated
 by this
 - *    API.
 + *    API. For restricted DMA pool, this is device tree
 adjustable.
>>>
>>> Maybe write it as this is "firmware adjustable" such that when/if ACPI
>>> needs something like this, the description does not need updating.
> 
> TBH I really don't think this needs calling out at all. Even in the
> regular case, the details of exactly how and where the pool is allocated
> are beyond the scope of this code - architectures already have several
> ways to control that and make their own decisions.
> 
>>>
>>> [snip]
>>>
 +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
 +    struct device *dev)
 +{
 +    struct io_tlb_mem *mem = rmem->priv;
 +    int ret;
 +
 +    if (dev->dma_io_tlb_mem)
 +    return -EBUSY;
 +
 +    if (!mem) {
 +    mem = kzalloc(sizeof(*mem), GFP_KERNEL);
 +    if (!mem)
 +    return -ENOMEM;
 +
 +    if (!memremap(rmem->base, rmem->size, MEMREMAP_WB)) {
>>>
>>> MEMREMAP_WB sounds appropriate as a default.
>>
>> As per the binding 'no-map' has to be disabled here. So AFAIU, this
>> memory will
>> be part of the linear mapping. Is this really needed then?
> 
> More than that, I'd assume that we *have* to use the linear/direct map
> address rather than anything that has any possibility of being a vmalloc
> remap, otherwise we can no longer safely rely on
> phys_to_dma/dma_to_phys, no?

I believe you are right, which means that if we want to make use of the
restricted DMA pool on a 32-bit architecture (and we do, at least, I do)
we should probably add some error checking/warning to ensure the
restricted DMA pool falls within the linear map.
-- 
Florian

Re: [PATCH] xen/iommu: smmu: Use 1UL << 31 rather than 1 << 31

[Julien Grall]

Hi Hans,

Sorry for the late reply.

On 24/12/2020 19:48, Hans van Kranenburg wrote:

On 12/24/20 4:24 PM, Julien Grall wrote:

From: Julien Grall 

Replace all the use of 1 << 31 with 1UL << 31 to prevent undefined
behavior in the SMMU driver.


You're replacing it by 1U, not 1UL, in the patch below.


Thank you for pointing that out! Stefano fixed it on commit.

Cheers,

--
Julien Grall

Re: Proposal - lightweight auto test binaries

[Marek Marczykowski-Górecki]

On Wed, Jan 13, 2021 at 03:45:10PM +, Andrew Cooper wrote:
> On 12/01/2021 17:35, Ian Jackson wrote:
> >  * When appropriately configured, the xen.git build system
> >will ship them into dist/install/usr/local/
> >
> >  * There will be a specific directory containing tests which
> >are suitable for running automatically:
> >   dist/install/usr/local/lib/xen/autotests
> >
> >  * The pass/success reporting API will be encoded into the
> >filename.  For now we define only one API:
> >  dist/install/usr/local/lib/xen/autotests/simple/*
> 
> Whatever we go for, it ought to be an easy path, and honestly - that's a
> mouthful to get to.  These tests need to be just as easy for developers
> to use.
> 
> How about opt/xen-autotest/* ?  Much easier in a deb/rpm build to filter
> the things which clearly shouldn't be in a production system.  It's also
> invariant of libdir which is an advantage for downstreams who test on
> more than one distro.

I can see them being packaged as a separate sub-package instead of not
packaging at all. And many distributions have rules forbidding native
packages form putting stuff into /opt. So a location somewhere in /usr
would be preferable.
I'm fine with dist/install/usr/local/lib/xen/autotests.
For running manually, there could be a trivial test runner (shell
script) that could be installed into dist/install/usr/local/sbin - to
make it even more convenient to access.

> I certainly have plans to reuse this infrastructure in XenRT.  I expect
> other downstreams would as well.
> 
> > The "simple" test API is as follows:
> >
> >  * Every executable file (or symlink to one) in
> >  dist/install/usr/local/lib/xen/autotests/simple/
> >will be run with no arguments.
> >
> >  * Only files whose names contain only [-0-9a-z] will be run.
> >Others will be ignored.  NB _ is not allowed.
> 
> I'm happy not using _, but why the restriction?
> 
> >  * A test may exit with one of the XTF exit statuses:
> >   0 # XTF SUCCESS
> >   3 # XTF SKIP
> >   4 # XTF ERROR
> >   5 # XTF FAILURE
> >   6 # XTF CRASH
> >(osstest will treat anything other than 0 and 3 as "fail")
> >Any other termination should be treated as CRASH.
> >
> >  * If a test exits nonzero it should print some information about
> >the situation to stderr.
> >
> >  * Tests may print other information to stderr, which will be captured
> >and logged.
> >
> >  * Tests *must not* print anything to stdout.  Test runners *must*
> >ignore stdout (though they may log it, possibly mixed in with
> >stderr).  stdout is reserved for future extension.
> 
> I disagree.  It is far more important that the tests are pleasant for
> humans to use, both in terms of developing them to begin with, and
> maintaining them if they go wrong.

I can see why such restriction would be useful for future extensions,
but I don't think it's strictly necessary. An extension can for example
require stdout lines with a specific prefix and ignore others.

> In practice, this means human-useful stuff on stdout.  The test
> automation does not need to care - all it should do is log
> stdout/stderr, and act upon the exit code.  (Perhaps this is what you
> meant, but its not clear IMO.)
> 
> 
> >  * Tests should exit with XTF ERROR if they are passed any arguments.
> 
> ./test-foo --debug-this-harder would be a perfectly reasonable thing for
> a human to use to investigate problems, and it is what we use in the
> fuzzing harnesses for investigating crashes.

A data point: libvirt test suite have very same requirement - test
binaries needs to be run without an argument and error when they get
one. In addition to the error, you get a help message with env variables
to use instead (VIR_TEST_DEBUG=1 for example). And I do run it with some
dummy argument, to get this help message, because I can't remember how
those variables are named. Every single time.
But TBH, if parameters wouldn't be very obvious (like --verbose, or
--debug), I'd run --help first too.

In any case, unknown command like arguments should result in an error.

> The problem is "for these configurations".  Even at the totally basic level,
> 
> * PV and Shadow are conditional on Xen's Kconfig.
> * PV32 is further conditional on command line settings, and/or whether
> the hardware supports CET-SS.
> * HVM is dependent on Kconfig, hardware, firmware and command line
> settings.  HAP similarly.
> 
> `xl create` doesn't handle missing CONFIG_SHADOW, or PV32 being disabled
> cleanly, despite having suitable information available in `xl info`. 
> While this can (and should) be fixed, its not helpful for the more
> general testing case.

It indeed is an issue, but in practice this can be worked up
incrementally - when the test fails, see if the reason is unsupported
(by the test) configuration. And if so - add a condition for this
specific case (to return SKIP or choose another configuration). Rinse
and repeat.

> At the

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Robin Murphy]

On 2021-01-13 17:43, Florian Fainelli wrote:

On 1/13/21 7:27 AM, Robin Murphy wrote:

On 2021-01-13 13:59, Nicolas Saenz Julienne wrote:

Hi All,

On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:

On 1/5/21 7:41 PM, Claire Chang wrote:

Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes in the device tree.

Signed-off-by: Claire Chang 
---
   include/linux/device.h  |   4 ++
   include/linux/swiotlb.h |   7 +-
   kernel/dma/Kconfig  |   1 +
   kernel/dma/swiotlb.c    | 144
++--
   4 files changed, 131 insertions(+), 25 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 89bb8b84173e..ca6f71ec8871 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -413,6 +413,7 @@ struct dev_links_info {
    * @dma_pools:    Dma pools (if dma'ble device).
    * @dma_mem:    Internal for coherent mem override.
    * @cma_area:    Contiguous memory area for dma allocations
+ * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
    * @archdata:    For arch-specific additions.
    * @of_node:    Associated device tree node.
    * @fwnode:    Associated device node supplied by platform firmware.
@@ -515,6 +516,9 @@ struct device {
   #ifdef CONFIG_DMA_CMA
   struct cma *cma_area;    /* contiguous memory area for dma
  allocations */
+#endif
+#ifdef CONFIG_SWIOTLB
+    struct io_tlb_mem    *dma_io_tlb_mem;
   #endif
   /* arch specific additions */
   struct dev_archdata    archdata;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index dd8eb57cbb8f..a1bbd775 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -76,12 +76,13 @@ extern enum swiotlb_force swiotlb_force;
    *
    * @start:    The start address of the swiotlb memory pool. Used
to do a quick
    *    range check to see if the memory was in fact allocated
by this
- *    API.
+ *    API. For restricted DMA pool, this is device tree
adjustable.


Maybe write it as this is "firmware adjustable" such that when/if ACPI
needs something like this, the description does not need updating.


TBH I really don't think this needs calling out at all. Even in the
regular case, the details of exactly how and where the pool is allocated
are beyond the scope of this code - architectures already have several
ways to control that and make their own decisions.



[snip]


+static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
+    struct device *dev)
+{
+    struct io_tlb_mem *mem = rmem->priv;
+    int ret;
+
+    if (dev->dma_io_tlb_mem)
+    return -EBUSY;
+
+    if (!mem) {
+    mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+    if (!mem)
+    return -ENOMEM;
+
+    if (!memremap(rmem->base, rmem->size, MEMREMAP_WB)) {


MEMREMAP_WB sounds appropriate as a default.


As per the binding 'no-map' has to be disabled here. So AFAIU, this
memory will
be part of the linear mapping. Is this really needed then?


More than that, I'd assume that we *have* to use the linear/direct map
address rather than anything that has any possibility of being a vmalloc
remap, otherwise we can no longer safely rely on
phys_to_dma/dma_to_phys, no?


I believe you are right, which means that if we want to make use of the
restricted DMA pool on a 32-bit architecture (and we do, at least, I do)
we should probably add some error checking/warning to ensure the
restricted DMA pool falls within the linear map.


Oh, good point - I'm so used to 64-bit that I instinctively just blanked 
out the !PageHighMem() condition in try_ram_remap(). So maybe the 
original intent here *was* to effectively just implement that check, but 
if so it could still do with being a lot more explicit.


Cheers,
Robin.

Re: [PATCH] x86/dpci: remove the dpci EOI timer

[Roger Pau Monné]

On Wed, Jan 13, 2021 at 10:48:52AM -0500, Jason Andryuk wrote:
> On Wed, Jan 13, 2021 at 8:11 AM Roger Pau Monné  wrote:
> >
> > On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monne 
> > > > Sent: Wednesday, January 13, 2021 1:33 AM
> > > >
> > > > Current interrupt pass though code will setup a timer for each
> > > > interrupt injected to the guest that requires an EOI from the guest.
> > > > Such timer would perform two actions if the guest doesn't EOI the
> > > > interrupt before a given period of time. The first one is deasserting
> > > > the virtual line, the second is perform an EOI of the physical
> > > > interrupt source if it requires such.
> > > >
> > > > The deasserting of the guest virtual line is wrong, since it messes
> > > > with the interrupt status of the guest. It's not clear why this was
> > > > odne in the first place, it should be the guest the one to EOI the
> > > > interrupt and thus deassert the line.
> > > >
> > > > Performing an EOI of the physical interrupt source is redundant, since
> > > > there's already a timer that takes care of this for all interrupts,
> > > > not just the HVM dpci ones, see irq_guest_action_t struct eoi_timer
> > > > field.
> > > >
> > > > Since both of the actions performed by the dpci timer are not
> > > > required, remove it altogether.
> > > >
> > > > Signed-off-by: Roger Pau Monné 
> > > > ---
> > > > As with previous patches, I'm having a hard time figuring out why this
> > > > was required in the first place. I see no reason for Xen to be
> > > > deasserting the guest virtual line. There's a comment:
> > > >
> > > > /*
> > > >  * Set a timer to see if the guest can finish the interrupt or not. For
> > > >  * example, the guest OS may unmask the PIC during boot, before the
> > > >  * guest driver is loaded. hvm_pci_intx_assert() may succeed, but the
> > > >  * guest will never deal with the irq, then the physical interrupt line
> > > >  * will never be deasserted.
> > > >  */
> > > >
> > > > Did this happen because the device was passed through in a bogus state
> > > > where it would generate interrupts without the guest requesting
> > >
> > > It could be a case where two devices share the same interrupt line and
> > > are assigned to different domains. In this case, the interrupt activity of
> > > two devices interfere with each other.
> >
> > This would also seem to be problematic if the device decides to use
> > MSI instead of INTx, but due to the shared nature of the INTx line we
> > would continue to inject INTx (generated from another device not
> > passed through to the guest) to the guest even if the device has
> > switched to MSI.
> >
> > > >
> > > > Won't the guest face the same issues when booted on bare metal, and
> > > > thus would already have the means to deal with such issues?
> > >
> > > The original commit was added by me in ~13yrs ago (0f843ba00c95)
> > > when enabling Xen in a client virtualization environment where interrupt
> > > sharing is popular.
> >
> > Thanks, the reference to the above commit is helpful, I wasn't able to
> > find it and it contains a comment that I think has been lost, which
> > provides the background on why this was added.
> >
> > > I believe above comment was recorded for a real
> > > problem at the moment (deassert resets the intx line to unblock further
> > > interrupts). But I'm not sure whether it is still the case after both Xen 
> > > and
> > > guest OS have changed a lot. At least some test from people who
> > > still use Xen in shared interrupt scenario would be helpful. Or, if such
> > > usage is already niche, maybe we can consider disallow passing through
> > > devices which share the same interrupt line to different domains and
> > > then safely remove this dpci EOI trick.
> >
> > So the deassert done by timeout only deasserts the virtual line, but
> > doesn't for example clear the IRR bit from the vIO-APIC pin, which
> > will cause further interrupts to not be delivered anyway until a
> > proper EOI (or a switch to trigger mode) is done to the pin.
> >
> > I think it's going to be complicated for me to find a system that has
> > two devices I can passthrough sharing the same GSI.
> 
> I have some laptops running OpenXT where the USB controller and NIC
> share an interrupt, and I assign them to different domains.  Qubes
> would hit this as well.

Is there any chance you could try the patch and see if you can hit the
issue it was trying to fix?

It would be good to be able to reproduce it so that I could work on an
alternative fix that doesn't require having two timers for each IRQ in
flight.

> (I hoped MSI translate would help me sidestep the need to XSM label
> the shared PIRQ, but as the other thread mentions, qemu-upstream
> doesn't support that.  I started using this instead:
> https://lore.kernel.org/xen-devel/20201019200318.103781-1-jandr...@gmail.com/)

MSI translate is also on my sight for removal, as you have seen from
that other thread :).

Th

Re: Inconsistent console behavior during HVM direct boot

[Roger Pau Monné]

On Wed, Jan 13, 2021 at 10:48:02AM -0500, Tamas K Lengyel wrote:
> On Wed, Jan 13, 2021 at 8:18 AM Roger Pau Monné  wrote:
> >
> > On Tue, Jan 12, 2021 at 09:54:18PM -0500, Tamas K Lengyel wrote:
> > > While direct booting a Linux kernel into an HVM VM no console output
> > > is received if serial="pty" is set in the VM config but the kernel
> > > command line specifies "console=hvc0". If "console=ttyS0" is specified
> > > then the console output is received as expected. Conversely, if the
> > > serial line is commented out in the VM config but hvc0 is set on the
> > > kernel command line then it also works. It's unclear whether this
> > > behavior is expected or not, after some discussion it sounds like all
> > > kernels ought to understand hvc0 irrespective of the serial="pty" line
> > > being set or not. Reporting this in case someone has more insight
> > > and/or inclination digging into this.
> >
> > So I think this is (as confusing as it might seem) the intended
> > behavior.
> >
> > Using serial='pty' exposes an emulated serial device to the guest and
> > 'xl console' will fetch the output from that device by default. So on
> > the Linux kernel command line you need to use console=ttyS0 in order
> > to point Linux to use the emulated serial device.
> >
> > however if serial='pty' is not used, there will be no emulated serial
> > device exposed to the guest, only the PV console, and that's what 'xl
> > console' will attach to in that case. You then need to point the Linux
> > kernel to use the PV serial console, by adding the console=hvc0
> > command line.
> >
> > I'm unsure how to clarify this, maybe some additions could be made to
> > the xl.cfg man page to note that using serial='pty' will add an
> > emulated serial device to the guest, and that by default 'xl console'
> > will fetch the output from that device instead of the paravirtualized
> > console?
> 
> Hi Roger,
> that explanation makes sense, I wasn't aware that there would be two
> different console's available to the guest if serial="pty" is set and
> that xl would pick on over the other. So adding that to the
> documentation would be helpful. Perhaps also pointing out under what
> scenario is the emulated console vs the pv console is useful. I assume
> the point of the emulated console would be to get console output from
> software that's not Xen-aware (like GRUB)?

Right, since you can run unmodified OSes (or bootloaders) in HVM mode
it's useful to be able to get serial output from them directly when
using 'xl console' IMO.

Would you be up for writing a patch to xl.cfg man page to clarify
it?

Thanks, Roger.

Re: [RFC PATCH v3 4/6] swiotlb: Add restricted DMA alloc/free support.

[Robin Murphy]

On 2021-01-13 12:48, Christoph Hellwig wrote:

+#ifdef CONFIG_SWIOTLB
+   if (unlikely(dev->dma_io_tlb_mem))
+   return swiotlb_alloc(dev, size, dma_handle, attrs);
+#endif


Another place where the dma_io_tlb_mem is useful to avoid the ifdef.


-phys_addr_t swiotlb_tbl_map_single(struct device *hwdev, phys_addr_t orig_addr,
-   size_t mapping_size, size_t alloc_size,
-   enum dma_data_direction dir, unsigned long attrs)
+static int swiotlb_tbl_find_free_region(struct device *hwdev,
+   dma_addr_t tbl_dma_addr,
+   size_t alloc_size,
+   unsigned long attrs)



+static void swiotlb_tbl_release_region(struct device *hwdev, int index,
+  size_t size)


This refactoring should be another prep patch.



+void *swiotlb_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+   unsigned long attrs)


I'd rather have the names convey there are for the per-device bounce
buffer in some form.


+   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;


While we're at it I wonder if the io_tlb is something we could change
while we're at it.  Maybe replace io_tlb_mem with struct swiotlb
and rename the field in struct device to dev_swiotlb?


+   int index;
+   void *vaddr;
+   phys_addr_t tlb_addr;
+
+   size = PAGE_ALIGN(size);
+   index = swiotlb_tbl_find_free_region(dev, mem->start, size, attrs);
+   if (index < 0)
+   return NULL;
+
+   tlb_addr = mem->start + (index << IO_TLB_SHIFT);
+   *dma_handle = phys_to_dma_unencrypted(dev, tlb_addr);
+
+   if (!dev_is_dma_coherent(dev)) {
+   unsigned long pfn = PFN_DOWN(tlb_addr);
+
+   /* remove any dirty cache lines on the kernel alias */
+   arch_dma_prep_coherent(pfn_to_page(pfn), size);


Can we hook in somewhat lower level in the dma-direct code so that all
the remapping in dma-direct can be reused instead of duplicated?  That
also becomes important if we want to use non-remapping uncached support,
e.g. on mips or x86, or the direct changing of the attributes that Will
planned to look into for arm64.


Indeed, AFAICS this ought to boil down to a direct equivalent of 
__dma_direct_alloc_pages() - other than the address there should be no 
conceptual difference between pages from the restricted pool and those 
from the regular page allocator, so this probably deserves to be plumbed 
in as an alternative to that.


Robin.

Re: [PATCH v2 2/2] xen/arm: Add defensive barrier in get_cycles for Arm64

[Julien Grall]

On 09/01/2021 12:16, Wei Chen wrote:

HI Julien,


Hi Wei,


-Original Message-
From: Julien Grall 
Sent: 2021年1月8日 19:56
To: Wei Chen ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org
Cc: Bertrand Marquis ; Penny Zheng
; Jiamei Xie ; nd

Subject: Re: [PATCH v2 2/2] xen/arm: Add defensive barrier in get_cycles for
Arm64

Hi Wei,

On 08/01/2021 06:21, Wei Chen wrote:

Per the discussion [1] on the mailing list, we'd better to
have a barrier after reading CNTPCT in get_cycles. If there
is not any barrier there. When get_cycles being used in some
seqlock critical context in the future, the seqlock can be
speculated potentially.

We import Linux commit 75a19a0202db21638a1c2b424afb867e1f9a2376:
  arm64: arch_timer: Ensure counter register reads occur with seqlock held

  When executing clock_gettime(), either in the vDSO or via a system call,
  we need to ensure that the read of the counter register occurs within
  the seqlock reader critical section. This ensures that updates to the
  clocksource parameters (e.g. the multiplier) are consistent with the
  counter value and therefore avoids the situation where time appears to
  go backwards across multiple reads.

  Extend the vDSO logic so that the seqlock critical section covers the
  read of the counter register as well as accesses to the data page. Since
  reads of the counter system registers are not ordered by memory barrier
  instructions, introduce dependency ordering from the counter read to a
  subsequent memory access so that the seqlock memory barriers apply to
  the counter access in both the vDSO and the system call paths.

  Cc: 
  Cc: Marc Zyngier 
  Tested-by: Vincenzo Frascino 
  Link: https://lore.kernel.org/linux-arm-

kernel/alpine.deb.2.21.1902081950260.1...@nanos.tec.linutronix.de/

  Reported-by: Thomas Gleixner 
  Signed-off-by: Will Deacon 

While we are not aware of such use in Xen, it would be best to add the
barrier to avoid any suprise.

In order to reduce the impact of new barrier, we perfer to
use enforce order instead of ISB [2].

Currently, enforce order is not applied to arm32 as this is
not done in Linux at the date of this patch. If this is done
in Linux it will need to be also done in Xen.

[1] https://lists.xenproject.org/archives/html/xen-devel/2020-

12/msg00181.html

[2] https://lkml.org/lkml/2020/3/13/645

Signed-off-by: Wei Chen 
---
v1 -> v2:
1. Update commit message to refer Linux commit.
2. Change u64 to uint64_t
---
   xen/include/asm-arm/time.h | 43

--

   1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
index 5c4529ebb5..6b8fd839dd 100644
--- a/xen/include/asm-arm/time.h
+++ b/xen/include/asm-arm/time.h
@@ -11,9 +11,26 @@

   typedef uint64_t cycles_t;

-static inline cycles_t get_cycles(void)
+/*
+ * Ensure that reads of the counter are treated the same as memory reads
+ * for the purposes of ordering by subsequent memory barriers.
+ */
+#if defined(CONFIG_ARM_64)
+#define read_cntpct_enforce_ordering(val) do { \
+uint64_t tmp, _val = (val);\
+   \
+asm volatile(  \
+"eor %0, %1, %1\n" \
+"add %0, sp, %0\n" \
+"ldr xzr, [%0]"\
+: "=r" (tmp) : "r" (_val));\
+} while (0)
+#else
+#define read_cntpct_enforce_ordering(val) do {} while (0)
+#endif
+
+static inline cycles_t read_cntpct_stable(void)


OOI, is there any particular reason to create a new helper?



Yes, I try to reduce the #if defined(CONFIG_ARM_64) chunks.


Hmmm... There is no #ifdef chunk in read_cntpct_stable(). Did I miss 
anything?



I think
if we introduce an empty helper for Arm32, we can reduce the other
chunk inside get_cycles. In addition, if we need to do the same work
for Arm32 in the future, we may not need to modify get_cycles.
I don't really follow this. I wasn't asking about 
read_cntpct_enforce_ordering(). Instead I was asking about 
read_cntpct_stable() which looks like you just split get_cycles().


This change looks completely unrelated to the purpose of this series. I 
am not going to ask to split it, but I think this should be explained in 
the commit message.


Cheers,

--
Julien Grall

Re: [RFC PATCH v3 4/6] swiotlb: Add restricted DMA alloc/free support.

[Christoph Hellwig]

On Wed, Jan 13, 2021 at 06:27:08PM +, Robin Murphy wrote:
>> Can we hook in somewhat lower level in the dma-direct code so that all
>> the remapping in dma-direct can be reused instead of duplicated?  That
>> also becomes important if we want to use non-remapping uncached support,
>> e.g. on mips or x86, or the direct changing of the attributes that Will
>> planned to look into for arm64.
>
> Indeed, AFAICS this ought to boil down to a direct equivalent of 
> __dma_direct_alloc_pages() - other than the address there should be no 
> conceptual difference between pages from the restricted pool and those from 
> the regular page allocator, so this probably deserves to be plumbed in as 
> an alternative to that.

Yes, that's what I mean.  You managed to word it much better, though.

Re: [PATCH] x86/dpci: remove the dpci EOI timer

[Jason Andryuk]

On Wed, Jan 13, 2021 at 1:06 PM Roger Pau Monné  wrote:
>
> On Wed, Jan 13, 2021 at 10:48:52AM -0500, Jason Andryuk wrote:
> > On Wed, Jan 13, 2021 at 8:11 AM Roger Pau Monné  
> > wrote:
> > >
> > > On Wed, Jan 13, 2021 at 06:21:03AM +, Tian, Kevin wrote:
> > > > > From: Roger Pau Monne 
> > > > > Sent: Wednesday, January 13, 2021 1:33 AM
> > > > >
> > > > > Current interrupt pass though code will setup a timer for each
> > > > > interrupt injected to the guest that requires an EOI from the guest.
> > > > > Such timer would perform two actions if the guest doesn't EOI the
> > > > > interrupt before a given period of time. The first one is deasserting
> > > > > the virtual line, the second is perform an EOI of the physical
> > > > > interrupt source if it requires such.
> > > > >
> > > > > The deasserting of the guest virtual line is wrong, since it messes
> > > > > with the interrupt status of the guest. It's not clear why this was
> > > > > odne in the first place, it should be the guest the one to EOI the
> > > > > interrupt and thus deassert the line.
> > > > >
> > > > > Performing an EOI of the physical interrupt source is redundant, since
> > > > > there's already a timer that takes care of this for all interrupts,
> > > > > not just the HVM dpci ones, see irq_guest_action_t struct eoi_timer
> > > > > field.
> > > > >
> > > > > Since both of the actions performed by the dpci timer are not
> > > > > required, remove it altogether.
> > > > >
> > > > > Signed-off-by: Roger Pau Monné 
> > > > > ---
> > > > > As with previous patches, I'm having a hard time figuring out why this
> > > > > was required in the first place. I see no reason for Xen to be
> > > > > deasserting the guest virtual line. There's a comment:
> > > > >
> > > > > /*
> > > > >  * Set a timer to see if the guest can finish the interrupt or not. 
> > > > > For
> > > > >  * example, the guest OS may unmask the PIC during boot, before the
> > > > >  * guest driver is loaded. hvm_pci_intx_assert() may succeed, but the
> > > > >  * guest will never deal with the irq, then the physical interrupt 
> > > > > line
> > > > >  * will never be deasserted.
> > > > >  */
> > > > >
> > > > > Did this happen because the device was passed through in a bogus state
> > > > > where it would generate interrupts without the guest requesting
> > > >
> > > > It could be a case where two devices share the same interrupt line and
> > > > are assigned to different domains. In this case, the interrupt activity 
> > > > of
> > > > two devices interfere with each other.
> > >
> > > This would also seem to be problematic if the device decides to use
> > > MSI instead of INTx, but due to the shared nature of the INTx line we
> > > would continue to inject INTx (generated from another device not
> > > passed through to the guest) to the guest even if the device has
> > > switched to MSI.
> > >
> > > > >
> > > > > Won't the guest face the same issues when booted on bare metal, and
> > > > > thus would already have the means to deal with such issues?
> > > >
> > > > The original commit was added by me in ~13yrs ago (0f843ba00c95)
> > > > when enabling Xen in a client virtualization environment where interrupt
> > > > sharing is popular.
> > >
> > > Thanks, the reference to the above commit is helpful, I wasn't able to
> > > find it and it contains a comment that I think has been lost, which
> > > provides the background on why this was added.
> > >
> > > > I believe above comment was recorded for a real
> > > > problem at the moment (deassert resets the intx line to unblock further
> > > > interrupts). But I'm not sure whether it is still the case after both 
> > > > Xen and
> > > > guest OS have changed a lot. At least some test from people who
> > > > still use Xen in shared interrupt scenario would be helpful. Or, if such
> > > > usage is already niche, maybe we can consider disallow passing through
> > > > devices which share the same interrupt line to different domains and
> > > > then safely remove this dpci EOI trick.
> > >
> > > So the deassert done by timeout only deasserts the virtual line, but
> > > doesn't for example clear the IRR bit from the vIO-APIC pin, which
> > > will cause further interrupts to not be delivered anyway until a
> > > proper EOI (or a switch to trigger mode) is done to the pin.
> > >
> > > I think it's going to be complicated for me to find a system that has
> > > two devices I can passthrough sharing the same GSI.
> >
> > I have some laptops running OpenXT where the USB controller and NIC
> > share an interrupt, and I assign them to different domains.  Qubes
> > would hit this as well.
>
> Is there any chance you could try the patch and see if you can hit the
> issue it was trying to fix?

Would testing a backport to 4.12 be useful?  There were some file
renames, but it looks to apply.  The only difference is the 4.12
hvm_pirq_eoi hunk still has `(ent && ent->fields.mask) || `.  Maybe
backport commit eb298f32fac5ac "x86/dpci: EOI in

Re: [PATCH v2] lib: drop (replace) debug_build()

[Julien Grall]

Hi Jan,

On 23/12/2020 16:05, Jan Beulich wrote:

Its expansion shouldn't be tied to NDEBUG - down the road we may want to
allow enabling assertions independently of CONFIG_DEBUG. Replace the few
uses by a new xen_build_info() helper, subsuming gcov_string at the same
time (while replacing the stale CONFIG_GCOV used there) and also adding
CONFIG_UBSAN indication.

Signed-off-by: Jan Beulich 


For the Arm code:

Acked-by: Julien Grall 

Cheers,


---
v2: Introduce xen_build_info() including also gcov and ubsan info.

--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -175,14 +175,14 @@ static void print_xen_info(void)
  {
  char taint_str[TAINT_STRING_MAX_LEN];
  
-printk("[ Xen-%d.%d%s  %s  debug=%c " gcov_string "  %s ]\n",

+printk("[ Xen-%d.%d%s  %s  %s  %s ]\n",
 xen_major_version(), xen_minor_version(), xen_extra_version(),
  #ifdef CONFIG_ARM_32
 "arm32",
  #else
 "arm64",
  #endif
-   debug_build() ? 'y' : 'n', print_tainted(taint_str));
+   xen_build_info(), print_tainted(taint_str));
  }
  
  #ifdef CONFIG_ARM_32

--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -29,9 +29,9 @@ static void print_xen_info(void)
  {
  char taint_str[TAINT_STRING_MAX_LEN];
  
-printk("[ Xen-%d.%d%s  x86_64  debug=%c " gcov_string "  %s ]\n",

+printk("[ Xen-%d.%d%s  x86_64  %s  %s ]\n",
 xen_major_version(), xen_minor_version(), xen_extra_version(),
-   debug_build() ? 'y' : 'n', print_tainted(taint_str));
+   xen_build_info(), print_tainted(taint_str));
  }
  
  enum context { CTXT_hypervisor, CTXT_pv_guest, CTXT_hvm_guest };

--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -70,6 +70,30 @@ const char *xen_deny(void)
  return "";
  }
  
+static const char build_info[] =

+"debug="
+#ifdef CONFIG_DEBUG
+"y"
+#else
+"n"
+#endif
+#ifdef CONFIG_COVERAGE
+# ifdef __clang__
+" llvmcov=y"
+# else
+" gcov=y"
+# endif
+#endif
+#ifdef CONFIG_UBSAN
+" ubsan=y"
+#endif
+"";
+
+const char *xen_build_info(void)
+{
+return build_info;
+}
+
  static const void *build_id_p __read_mostly;
  static unsigned int build_id_len __read_mostly;
  
--- a/xen/drivers/char/console.c

+++ b/xen/drivers/char/console.c
@@ -1002,10 +1002,10 @@ void __init console_init_preirq(void)
  spin_lock(&console_lock);
  __putstr(xen_banner());
  spin_unlock(&console_lock);
-printk("Xen version %d.%d%s (%s@%s) (%s) debug=%c " gcov_string " %s\n",
+printk("Xen version %d.%d%s (%s@%s) (%s) %s %s\n",
 xen_major_version(), xen_minor_version(), xen_extra_version(),
-   xen_compile_by(), xen_compile_domain(),
-   xen_compiler(), debug_build() ? 'y' : 'n', xen_compile_date());
+   xen_compile_by(), xen_compile_domain(), xen_compiler(),
+   xen_build_info(), xen_compile_date());
  printk("Latest ChangeSet: %s\n", xen_changeset());
  
  /* Locate and print the buildid, if applicable. */

--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -48,21 +48,13 @@
  #define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond))
  #endif
  
-#ifdef CONFIG_GCOV

-#define gcov_string "gcov=y"
-#else
-#define gcov_string ""
-#endif
-
  #ifndef NDEBUG
  #define ASSERT(p) \
  do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
  #define ASSERT_UNREACHABLE() assert_failed("unreachable")
-#define debug_build() 1
  #else
  #define ASSERT(p) do { if ( 0 && (p) ) {} } while (0)
  #define ASSERT_UNREACHABLE() do { } while (0)
-#define debug_build() 0
  #endif
  
  #define ABS(_x) ({  \

--- a/xen/include/xen/version.h
+++ b/xen/include/xen/version.h
@@ -16,6 +16,7 @@ const char *xen_extra_version(void);
  const char *xen_changeset(void);
  const char *xen_banner(void);
  const char *xen_deny(void);
+const char *xen_build_info(void);
  int xen_build_id(const void **p, unsigned int *len);
  
  #ifdef BUILD_ID




--
Julien Grall

Re: [PATCH v2 1/2] include: don't use asm/page.h from common headers

[Julien Grall]

Hi Jan,

On 05/01/2021 12:37, Jan Beulich wrote:

Doing so limits what can be done in (in particular included by) this per-
arch header. Abstract out page shift/size related #define-s, which is all
the respective headers care about. Extend the replacement / removal to
some x86 headers as well; some others now need to include page.h (and
they really should have before).

Arm's VADDR_BITS gets dropped altogether: Its current value is clearly
wrong for 64-bit, but the constant also isn't used anywhere right now.

While Arm used vaddr_t in PAGE_OFFSET(), this use is compatible with
that of unsigned long in the new common implementation.

Also drop the dead PAGE_FLAG_MASK at this occasion.

Signed-off-by: Jan Beulich 


Acked-by: Julien Grall 

Cheers,


---
v2: Have just a single PAGE_OFFSET(). Rename per-arch headers to
 page-bits.h. Drop VADDR_BITS altogether for Arm.

--- a/xen/arch/arm/arm64/lib/clear_page.S
+++ b/xen/arch/arm/arm64/lib/clear_page.S
@@ -14,6 +14,8 @@
   * along with this program.  If not, see .
   */
  
+#include 

+
  /*
   * Clear page @dest
   *
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -176,11 +176,6 @@
  #define FIXMAP_ACPI_BEGIN  2  /* Start mappings of ACPI tables */
  #define FIXMAP_ACPI_END(FIXMAP_ACPI_BEGIN + NUM_FIXMAP_ACPI_PAGES - 1)  
/* End mappings of ACPI tables */
  
-#define PAGE_SHIFT  12

-#define PAGE_SIZE   (_AC(1,L) << PAGE_SHIFT)
-#define PAGE_MASK   (~(PAGE_SIZE-1))
-#define PAGE_FLAG_MASK  (~0)
-
  #define NR_hypercalls 64
  
  #define STACK_ORDER 3

--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -1,6 +1,7 @@
  #ifndef __ARM_CURRENT_H__
  #define __ARM_CURRENT_H__
  
+#include 

  #include 
  
  #include 

--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -2,21 +2,11 @@
  #define __ARM_PAGE_H__
  
  #include 

+#include 
  #include 
  #include 
  #include 
  
-#ifdef CONFIG_ARM_64

-#define PADDR_BITS  48
-#else
-#define PADDR_BITS  40
-#endif
-#define PADDR_MASK  ((1ULL << PADDR_BITS)-1)
-#define PAGE_OFFSET(ptr)((vaddr_t)(ptr) & ~PAGE_MASK)
-
-#define VADDR_BITS  32
-#define VADDR_MASK  (~0UL)
-
  /* Shareability values for the LPAE entries */
  #define LPAE_SH_NON_SHAREABLE 0x0
  #define LPAE_SH_UNPREDICTALE  0x1
--- /dev/null
+++ b/xen/include/asm-arm/page-bits.h
@@ -0,0 +1,12 @@
+#ifndef __ARM_PAGE_SHIFT_H__
+#define __ARM_PAGE_SHIFT_H__
+
+#define PAGE_SHIFT  12
+
+#ifdef CONFIG_ARM_64
+#define PADDR_BITS  48
+#else
+#define PADDR_BITS  40
+#endif
+
+#endif /* __ARM_PAGE_SHIFT_H__ */
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -8,8 +8,8 @@
  #define __X86_CURRENT_H__
  
  #include 

+#include 
  #include 
-#include 
  
  /*

   * Xen's cpu stacks are 8 pages (8-page aligned), arranged as:
--- a/xen/include/asm-x86/desc.h
+++ b/xen/include/asm-x86/desc.h
@@ -1,6 +1,8 @@
  #ifndef __ARCH_DESC_H
  #define __ARCH_DESC_H
  
+#include 

+
  /*
   * Xen reserves a memory page of GDT entries.
   * No guest GDT entries exist beyond the Xen reserved area.
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -12,7 +12,7 @@
  #ifndef _ASM_FIXMAP_H
  #define _ASM_FIXMAP_H
  
-#include 

+#include 
  
  #define FIXADDR_TOP (VMAP_VIRT_END - PAGE_SIZE)

  #define FIXADDR_X_TOP (XEN_VIRT_END - PAGE_SIZE)
--- a/xen/include/asm-x86/guest/hyperv-hcall.h
+++ b/xen/include/asm-x86/guest/hyperv-hcall.h
@@ -20,12 +20,12 @@
  #define __X86_HYPERV_HCALL_H__
  
  #include 

+#include 
  #include 
  
  #include 

  #include 
  #include 
-#include 
  
  static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input_addr,

 paddr_t output_addr)
--- a/xen/include/asm-x86/guest/hyperv-tlfs.h
+++ b/xen/include/asm-x86/guest/hyperv-tlfs.h
@@ -10,8 +10,8 @@
  #define _ASM_X86_HYPERV_TLFS_H
  
  #include 

+#include 
  #include 
-#include 
  
  /*

   * While not explicitly listed in the TLFS, Hyper-V always runs with a page 
size
--- a/xen/include/asm-x86/io.h
+++ b/xen/include/asm-x86/io.h
@@ -3,7 +3,6 @@
  
  #include 

  #include 
-#include 
  
  #define readb(x) (*(volatile uint8_t  *)(x))

  #define readw(x) (*(volatile uint16_t *)(x))
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -6,6 +6,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
--- a/xen/include/asm-x86/page.h

+++ b/xen/include/asm-x86/page.h
@@ -2,15 +2,7 @@
  #define __X86_PAGE_H__
  
  #include 

-
-/*
- * It is important that the masks are signed quantities. This ensures that
- * the compiler sign-extends a 32-bit mask to 64 bits if that is required.
- */
-#define PAGE_SIZE   (_AC(1,L) << PAGE_SHIFT)
-#define PAGE_MASK   (~(PAGE_SIZE-1))
-#define PAGE_FLAG_MASK  (~0)
-#define PAGE_OFFSET(ptr)((unsigned long

Re: [PATCH v2 2/2] mm: split out mfn_t / gfn_t / pfn_t definitions and helpers

[Julien Grall]

Hi Jan,

On 05/01/2021 12:38, Jan Beulich wrote:

xen/mm.h has heavy dependencies, while in a number of cases only these
type definitions are needed. This separation then also allows pulling in
these definitions when including xen/mm.h would cause cyclic
dependencies.

Replace xen/mm.h inclusion where possible in include/xen/. (In
xen/iommu.h also take the opportunity and correct the few remaining
sorting issues.)

While the change could be dropped, remove an unnecessary asm/io.h
inclusion from xen/arch/x86/acpi/power.c. This was the initial attempt
to address build issues with it, until it became clear that the header
itself needs adjustment.

Signed-off-by: Jan Beulich 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH 2/3] tools: Move xen-access from tests/ to misc/

[Tamas K Lengyel]

On Wed, Jan 13, 2021 at 7:35 AM Andrew Cooper  wrote:
>
> xen-access is a tool for a human to use, rather than a test.  Move it
> into misc/ as a more appropriate location to live.
>
> Move the -DXC_WANT_COMPAT_DEVICEMODEL_API from CFLAGS into xen-access.c itself
> to avoid adding Makefile complexity.

Acked-by: Tamas K Lengyel 

[PING] Re: [PATCH v2] xen/irq: Propagate the error from init_one_desc_irq() in init_*_irq_data()

[Julien Grall]

Hi all,

On 28/11/2020 11:36, Julien Grall wrote:

From: Julien Grall 

init_one_desc_irq() can return an error if it is unable to allocate
memory. While this is unlikely to happen during boot (called from
init_{,local_}irq_data()), it is better to harden the code by
propagting the return value.

Spotted by coverity.

CID: 106529

Signed-off-by: Julien Grall 
Reviewed-by: Roger Paul Monné 


From my understanding of MAINTAINERS rule, I still need an ack from x86 
maintainers.


Cheers,

--
Julien Grall

Re: [PATCH 2/3] tools: Move xen-access from tests/ to misc/

[Andrew Cooper]

On 13/01/2021 18:50, Tamas K Lengyel wrote:
> On Wed, Jan 13, 2021 at 7:35 AM Andrew Cooper  
> wrote:
>> xen-access is a tool for a human to use, rather than a test.  Move it
>> into misc/ as a more appropriate location to live.
>>
>> Move the -DXC_WANT_COMPAT_DEVICEMODEL_API from CFLAGS into xen-access.c 
>> itself
>> to avoid adding Makefile complexity.
> Acked-by: Tamas K Lengyel 

Thanks.  I'll also update the MAINTAINERs path, which I forgot to do.

~Andrew

Re: [PATCH] memory: avoid pointless continuation in xenmem_add_to_physmap()

[Julien Grall]

Hi Jan,

On 04/12/2020 10:43, Jan Beulich wrote:

Adjust so we uniformly avoid needlessly arranging for a continuation on
the last iteration.

Fixes: 5777a3742d88 ("IOMMU: hold page ref until after deferred TLB flush")


I view this patch as an optimization because there is nothing wrong with 
the code. So I think "Fixes" is not entirely suitable here.



Signed-off-by: Jan Beulich 

Other than my remark about the tag:

Reviewed-by: Julien Grall 

Cheers,



--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -854,8 +854,9 @@ int xenmem_add_to_physmap(struct domain
  ++extra.ppage;
  
  /* Check for continuation if it's not the last iteration. */

-if ( (++done >= ARRAY_SIZE(pages) && extra.ppage) ||
- (xatp->size > done && hypercall_preempt_check()) )
+if ( xatp->size > ++done &&
+ ((done >= ARRAY_SIZE(pages) && extra.ppage) ||
+  hypercall_preempt_check()) )
  {
  rc = start + done;
  break;



--
Julien Grall

Re: [PATCH] x86/mem_sharing: fix wrong field name used in 2c5119d

[Andrew Cooper]

On 13/01/2021 02:28, Tamas K Lengyel wrote:
> The arch_domain struct has "msr", not "msrs".
>
> Reported-by: Andrew Cooper 
> Signed-off-by: Tamas K Lengyel 
> ---
> I've build tested originally with "msr" but typod "msrs" when creating the
> patch that was sent in. Sorry for the noise.

Acked-by: Andrew Cooper 

It was actually a Travis Randconfig run which happened to turn
CONFIG_MEM_SHARING on.  I'll add words to that effect, but probably not
a URL as its about to cease to exist.

[xen-unstable test] 158399: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-xl-thunderx  8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-examine  8 reboot   fail REGR. vs. 158290
 test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-xl-xsm   8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-xl-credit2   8 xen-boot fail REGR. vs. 158290

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158290
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 158290
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 158290
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 158290
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 158290
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 158290
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 158290
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 158290
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 158290
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 158290
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 158290
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-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-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-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-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-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-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-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-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 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-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  414be7b66349e7dca42bc1fd47c2b2f5b2d27432
baseline version:
 xen  7ba2ab495be54f608cb47440e1497b2795bd301a

Last test of basis   158290  2021-01-09 01:51:29 Z4 days
Failing since158296  2021-01-09 11:08:42 Z4 days8 attempts
Testing same since   158399  2021-01-13 05:44:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bertrand Marquis 
  Jan Beulich 
  Julien Grall 
  Manuel Bouyer 
  Marek Marczykowski-Górecki 
  Olaf Hering 
  Oleksandr Tyshchenko 
  Roger Pau Monne 
  Roger Pau Monné 
  Roman Skakun 
  Stefano Stabellini 
  Stefano Stabellini 
  Tamas K Lengyel 
  Tamas K Lengyel 
  Tim Deegan 
  Volodymyr Babchyk 
  Wei Liu 

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

[linux-linus test] 158401: regressions - FAIL

[osstest service owner]

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

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-qemuu-rhel6hvm-intel  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-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 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-libvirt-xsm   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-coresched-i386-xl  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl7 xen-install  fail 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-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-shadow 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-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-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-amd64-xl-multivcpu 14 guest-start fail REGR. vs. 152332
 test-amd64-amd64-xl  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-xl-pvshim   14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-xl-credit2  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-xl-pvhv2-intel 14 guest-start   fail REGR. vs. 152332
 test-amd64-amd64-xl-shadow   14 guest-start  fail REGR. vs. 152332
 test-amd64-i386-examine   6 xen-install  fail REGR. vs. 152332
 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start   fail REGR. vs. 152332
 test-amd64-amd64-xl-pvhv2-amd 14 guest-start fail REGR. vs. 152332
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-libvirt 14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-xl-credit1  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-xl-xsm  14 guest-start  fail REGR. vs. 152332
 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 152332
 test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 152332
 test-amd64-amd64-libvirt-pair 25 guest-start/debian  fail REGR. vs. 152332
 test-arm64-arm64-xl-credit2   8 xen-boot fail REGR. vs. 152332
 test-amd64-coresched-amd64-xl 14 guest-start fail REGR. vs. 152332
 test-amd64-amd64-pair25 guest-start/debian   fail REGR. vs. 152332
 test-arm64-arm64-examine 13 examine-iommufail REGR. vs. 152332
 test-amd64-amd64-amd64-pvgrub 19 guest-localmigrate/x10  fail REGR. vs. 152332
 test-amd64-amd64-i386-pvgrub 20 guest-stop   fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-installfail 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-arm64-arm64-xl-seattle   8 xen-boot fail REGR. vs. 152332
 test-arm64-arm64-xl  10 host-ping-check-xen  fail REGR. vs. 152332
 test-arm64-arm64-xl-xsm   8 xen-boot fail REGR. vs. 152332

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 14 guest-start  fail REGR. vs. 152332

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm 11 leak-check/basis(11)fail blocked in 152332
 test-amd

Re: Purpose of translate MSI interrupt into INTx for guest passthrough

[Andrew Cooper]

On 12/01/2021 15:51, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 09:48:17AM -0500, Jason Andryuk wrote:
>> On Tue, Jan 12, 2021 at 9:25 AM Roger Pau Monné  wrote:
>>> Dropping Qing He as this address bounces.
>>>
>>> On Tue, Jan 12, 2021 at 03:10:57PM +0100, Roger Pau Monné wrote:
 Hello,

 While trying to do some cleanup of the Xen interrupt support for pci
 pass though I came across the MSI to INTx translation that Xen is in
 theory capable of performing (ie: use a physical MSI interrupt source
 and inject that as an INTx to a guest).

 AFAICT such functionality is not wired up to the toolstack, so it's
 hard to tell what's the indented purpose, or whether it has seen any
 usage.
>>> So apparently it is wired up to the toolstack for qemu-traditional,
>>> albeit it's disabled by default. There's some documentation in
>>> xl-pci-configuration:
>>>
>>> "When enabled, MSI-INTx translation will always enable MSI on the PCI
>>> device regardless of whether the guest uses INTx or MSI."
>>>
>>> So the main purpose seem to be to always use the MSI interrupt source
>>> regardless of whether the guest is using INTx or MSI. Maybe the
>>> purpose was to workaround some bugs when using INTx? Or buggy devices
>>> with INTx interrupts?
>>>
>>> qemu-upstream doesn't seem to support it anymore, so I would still
>>> like to remove it if we get consensus.
>> The cover letter from
>> http://old-list-archives.xenproject.org/archives/html/xen-devel/2009-01/msg00228.html
>> """
>> This patchset enables MSI-INTx interrupt translation for HVM
>> domains. The intention of the patch is to use MSI as the physical
>> interrupt mechanism for passthrough device as much as possible,
>> thus reducing the pirq sharing among domains.
>>
>> When MSI is globally enabled, if the device has the MSI capability
>> but doesn't used by the guest, hypervisor will try to user MSI as
>> the underlying pirq and inject translated INTx irq to guest
>> vioapic. When guest itself enabled MSI or MSI-X, the translation
>> is automatically turned off.
>>
>> Add a config file option to disable/enable this feature. Also, in
>> order to allow the user to override the option per device, a
>> per-device option mechanism is implemented and an MSI-INTx option
>> is added
>> """
>>
>> It seems like it could be a good idea, but I don't know if it presents
>> compatibility issues when actually used.
> Hm, MSI interrupts are edge triggered, while INTx is (usually) level.
> Also devices capable of multiple MSI vectors will be limited to a
> single one, and I'm not sure whether the transition from translated
> MSI to INTx into multiple MSIs would work correctly, as seems tricky.
>
>> As you say, it's not supported by qemu-upstream, so maybe it should
>> just be dropped.
> I don't really see much value in forcing Xen to always use MSI
> regardless of whether the guest is using INTx or MSI, and it's likely
> to cause more issues than benefits.
>
> IMO I think we should get rid of this, as the only real value is
> having Xen using MSI intend of INTx, but it's not introducing any kind
> of functionality from a guest PoV.

I find this feature very dubious.

While I agree that reducing INTx sharing between domains is obviously a
good thing, I don't see how the device can possibly be expected to work
if the in-guest driver doesn't have an accurate idea of what's going on.

There are up to 4 INTx lines, but absolutely nothing to suggest that
these would logically map to the first 4 MSIs enabled on the device. 
Even in the simplified case of only INTA and a single MSI, there's
nothing to suggest that the device will behave in the same way when it
comes to generating interrupts.

The difference between edge and line interrupts forces the guest driver
to explicitly de-assert the (what it thinks is a) line interrupt in a
device-specific manner, which in turn risks confusing the device which
is configured in MSI mode.

Also, it means Xen's emulation of edge=>line semantics has no clue when
to correctly deassert the line, without having device-specific knowledge
in the hypervisor, and appropriate trap&emulate intercepts on whatever
the devices deassert mechanism is.

I don't see how a feature like this can ever have worked, other than by
shear luck.

~Andrew

Re: [PATCH] kconfig: ensure strndup() declaration is visible

[Andrew Cooper]

On 11/01/2021 14:42, Jan Beulich wrote:
> Its guard was updated such that it is visible by default when POSIX 2008
> was adopted by glibc. It's not visible by default on older glibc.
>
> Fixes: f80fe2b34f08 ("xen: Update Kconfig to Linux v5.4")
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

Re: [PATCH] x86/dpci: remove the dpci EOI timer

[Jason Andryuk]

On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk  wrote:
>
> On Wed, Jan 13, 2021 at 1:06 PM Roger Pau Monné  wrote:
> >
> > On Wed, Jan 13, 2021 at 10:48:52AM -0500, Jason Andryuk wrote:



> > > I have some laptops running OpenXT where the USB controller and NIC
> > > share an interrupt, and I assign them to different domains.  Qubes
> > > would hit this as well.
> >
> > Is there any chance you could try the patch and see if you can hit the
> > issue it was trying to fix?
>
> Would testing a backport to 4.12 be useful?  There were some file
> renames, but it looks to apply.  The only difference is the 4.12
> hvm_pirq_eoi hunk still has `(ent && ent->fields.mask) || `.  Maybe
> backport commit eb298f32fac5ac "x86/dpci: EOI interrupt regardless of
> its masking status" as well?

Ok, I added these two patches to OpenXT with Xen 4.12.

> Testing staging would take a little longer to make a machine available.
>
> I guess I'd also need to disable MSI for the two devices to ensure
> they are both using the GSI?

lspci in dom0 shows the USB xhci controller, iwlwifi, and e1000e
devices all with IRQ 16 and all with MSI disabled ("MSI: Enabled-").
The two linux HVMs run with (PV) linux stubdoms, and the HVM kernels
were started with pci=nosmi.  Networking through the iwlwifi device
works for that VM while a mouse attached to the xhci controller is
also working in the second VM.  Is there something else I should test?

Regards,
Jason

[xen-unstable-smoke test] 158408: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 15 migrate-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-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  896128e9352327c4ff2b5c0c6cfa3856e45e2ca3
baseline version:
 xen  414be7b66349e7dca42bc1fd47c2b2f5b2d27432

Last test of basis   158388  2021-01-12 20:00:26 Z1 days
Testing same since   158408  2021-01-13 20:00:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Julien Grall 
  Tamas K Lengyel 
  Tamas K Lengyel 
  Wei Chen 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   414be7b663..896128e935  896128e9352327c4ff2b5c0c6cfa3856e45e2ca3 -> smoke

Re: [PATCH 3/5] argo: don't pointlessly use get_domain_by_id()

[Christopher Clark]

On Tue, Jan 5, 2021 at 5:26 AM Jan Beulich  wrote:
>
> For short-lived references rcu_lock_domain_by_id() is the better
> (slightly cheaper) alternative.

This should scale better than the existing use of get_domain_by_id.

I actually found it pretty hard to study the code for the effects of
switching over to use the RCU domain reference logic, and I would have
been happier with reviewing if I'd been able to exercise it with some
focused testing; XTF needs support for tests with multiple test VMs to
enable Argo tests of communication and interactions with hypervisor
state.

> Signed-off-by: Jan Beulich 

Acked-by: Christopher Clark 

> ---
> Is it really intentional for fill_ring_data() to return success (0) in
> case the domain can't be found or has argo disabled?

Good question; I think this logic can and should be improved. I will
work on a patch.

> Even if so, the
> uninitialized ent.max_message_size will be leaked to the caller then
> (and similarly when find_ring_info_by_match() returns NULL). Perhaps
> the field should only be copied back when ent.flags is non-zero?

Yes.

thanks,

Christopher

>
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -445,13 +445,13 @@ signal_domain(struct domain *d)
>  static void
>  signal_domid(domid_t domain_id)
>  {
> -struct domain *d = get_domain_by_id(domain_id);
> +struct domain *d = rcu_lock_domain_by_id(domain_id);
>
>  if ( !d )
>  return;
>
>  signal_domain(d);
> -put_domain(d);
> +rcu_unlock_domain(d);
>  }
>
>  static void
> @@ -983,7 +983,7 @@ ringbuf_insert(const struct domain *d, s
>  static void
>  wildcard_pending_list_remove(domid_t domain_id, struct pending_ent *ent)
>  {
> -struct domain *d = get_domain_by_id(domain_id);
> +struct domain *d = rcu_lock_domain_by_id(domain_id);
>
>  if ( !d )
>  return;
> @@ -996,13 +996,13 @@ wildcard_pending_list_remove(domid_t dom
>  list_del(&ent->wildcard_node);
>  spin_unlock(&d->argo->wildcard_L2_lock);
>  }
> -put_domain(d);
> +rcu_unlock_domain(d);
>  }
>
>  static void
>  wildcard_pending_list_insert(domid_t domain_id, struct pending_ent *ent)
>  {
> -struct domain *d = get_domain_by_id(domain_id);
> +struct domain *d = rcu_lock_domain_by_id(domain_id);
>
>  if ( !d )
>  return;
> @@ -1015,7 +1015,7 @@ wildcard_pending_list_insert(domid_t dom
>  list_add(&ent->wildcard_node, &d->argo->wildcard_pend_list);
>  spin_unlock(&d->argo->wildcard_L2_lock);
>  }
> -put_domain(d);
> +rcu_unlock_domain(d);
>  }
>
>  static void
> @@ -1283,7 +1283,7 @@ partner_rings_remove(struct domain *src_
>struct argo_send_info,
>node)) )
>  {
> -struct domain *dst_d = get_domain_by_id(send_info->id.domain_id);
> +struct domain *dst_d = 
> rcu_lock_domain_by_id(send_info->id.domain_id);
>
>  if ( dst_d && dst_d->argo )
>  {
> @@ -1302,7 +1302,7 @@ partner_rings_remove(struct domain *src_
>  ASSERT_UNREACHABLE();
>
>  if ( dst_d )
> -put_domain(dst_d);
> +rcu_unlock_domain(dst_d);
>
>  list_del(&send_info->node);
>  xfree(send_info);
> @@ -1330,7 +1330,7 @@ fill_ring_data(const struct domain *curr
>
>  ent.flags = 0;
>
> -dst_d = get_domain_by_id(ent.ring.domain_id);
> +dst_d = rcu_lock_domain_by_id(ent.ring.domain_id);
>  if ( !dst_d || !dst_d->argo )
>  goto out;
>
> @@ -1340,10 +1340,7 @@ fill_ring_data(const struct domain *curr
>   */
>  ret = xsm_argo_send(currd, dst_d);
>  if ( ret )
> -{
> -put_domain(dst_d);
> -return ret;
> -}
> +goto out;
>
>  read_lock(&dst_d->argo->rings_L2_rwlock);
>
> @@ -1405,7 +1402,7 @@ fill_ring_data(const struct domain *curr
>
>   out:
>  if ( dst_d )
> -put_domain(dst_d);
> +rcu_unlock_domain(dst_d);
>
>  if ( !ret && (__copy_field_to_guest(data_ent_hnd, &ent, flags) ||
>__copy_field_to_guest(data_ent_hnd, &ent, 
> max_message_size)) )
> @@ -1569,7 +1566,7 @@ unregister_ring(struct domain *currd,
>  if ( ring_id.partner_id == XEN_ARGO_DOMID_ANY )
>  goto out;
>
> -dst_d = get_domain_by_id(ring_id.partner_id);
> +dst_d = rcu_lock_domain_by_id(ring_id.partner_id);
>  if ( !dst_d || !dst_d->argo )
>  {
>  ASSERT_UNREACHABLE();
> @@ -1592,7 +1589,7 @@ unregister_ring(struct domain *currd,
>  read_unlock(&L1_global_argo_rwlock);
>
>  if ( dst_d )
> -put_domain(dst_d);
> +rcu_unlock_domain(dst_d);
>
>  xfree(send_info);
>
> @@ -1663,7 +1660,7 @@ register_ring(struct domain *currd,
>  }
>  else
>  {
> -dst_d = get_domain_by_id(reg.partner_id);
> +dst_d = rcu_lock_domain_by_id(reg.partner_id);
>  if ( !dst_d )
>

Re: [PATCH 1/5] common: don't (kind of) open-code rcu_lock_domain_by_any_id()

[Andrew Cooper]

On 05/01/2021 14:17, Jan Beulich wrote:
>>> ---
>>> Besides get_pg_owner(), gnttab_copy_lock_domain() has similar strange(?)
>>> behavior: They accept DOMID_SELF, but not the resolved ID of the caller.
>> I queried that behaviour years and years ago.
>>
>> According to Keir, it is part of the attempt to force guests to not know
>> their own domid.  Xen itself does (or did) its very hardest to prevent a
>> domU knowing its own domid, while at the same time the "domid" key in
>> xenstore is mandatory for setting up PV rings.
>>
>> I'd personally think was a short sighted move.
> Let me make another patch then, unless you can see reasons we should
> stick to the current behavior. Figuring out its own domid is possible
> for a domain, after all, and even shouldn't be overly difficult.

I don't see any reason to keep these semantics, other than the general
argument against relaxing things vs compatibility with older hypervisors.

I honestly can't make up my mind, so whichever you prefer.

~Andrew

Re: [PATCH 1/4] xen/dmalloc: Introduce dmalloc() APIs

[Andrew Cooper]

On 05/01/2021 15:56, Jan Beulich wrote:
> On 23.12.2020 17:34, Andrew Cooper wrote:
>> RFC:
>>  * This probably wants to be less fatal in release builds
> I'm not even convinced this wants to be a panic() in debug builds.

Any memory leak spotted by this is an XSA, except in the narrow case of
being due exclusively to a weird and non-default order of hypercalls.

It absolutely needs to be something fatal in debug builds, for avoid
going unnoticed by testing.  Patch 4 is my proposed solution for this,
which will hopefully prevent bugs from escaping staging.

For release builds, a real memory leak is less bad behaviour than taking
the host down, but it certainly shouldn't shouldn't go unnoticed.

>>  * In an ideal world, we'd also want to count the total number of bytes
>>allocated from the xmalloc heap, which would be interesting to print in 
>> the
>>'q' debugkey.  However, that data is fairly invasive to obtain.
> Unless we used an xmem_pool rather than the new interface being
> a thin layer around xmalloc(). (This would then also provide
> better locality of the allocations, i.e. different domains
> wouldn't share allocations from the same page.)

I'm not sure if using a separate memory pool is a clear cut improvement.

For an attacker which has a corruption primitive, a single shared pool
will reduce the chance of the exploit being stable across different
systems.  Improved locality of allocations is an advantage from the
attackers point of view, but the proper way to combat that is with a
real randomised heap allocator.

Sharing within the same page isn't an issue, so long as we respect a
cache line minimum allocation size.

More importantly however, until we know exactly how much memory we're
talking about here, switching to a per-domain pool might be a massive
waste.  The xmalloc() allocations are in the noise compared to RAM, and
might only be a small multiple of the pool metadata to begin with.

> And even without doing so, adding a function to retrieve the actual size
> shouldn't be all that difficult - internally xmalloc_tlsf.c
> knows the size, after all, for e.g. xrealloc() to work right.

Yeah - the internals of the pool can calculate this.  I was considering
doing just this, but wasn't sure how exposing an API for this would go down.

For maximum flexibility, it would be my preferred way forward.

>> --- /dev/null
>> +++ b/xen/include/xen/dmalloc.h
>> @@ -0,0 +1,29 @@
>> +#ifndef XEN_DMALLOC_H
>> +#define XEN_DMALLOC_H
>> +
>> +#include 
>> +
>> +struct domain;
>> +
>> +#define dzalloc_array(d, _type, _num)   \
> While I realize I'll get bashed again, the inconsistency of using
> (or not) leading underscores is too odd to not comment upon. I
> don't see what use they are here, irrespective of my general view
> on the topic.
>
>> +((_type *)_dzalloc_array(d, sizeof(_type), __alignof__(_type), _num))
>> +
>> +
>> +void dfree(struct domain *d, void *ptr);
> May I ask to avoid double blank lines?

Both of these were just copied from xmalloc.h without any real thought. 
What I did forget was to plaster this series with RFC.

>> +#define DFREE(d, p) \
>> +do {\
>> +dfree(d, p);\
>> +(p) = NULL; \
>> +} while ( 0 )
>> +
>> +
>> +void *_dzalloc(struct domain *d, size_t size, size_t align);
>> +
>> +static inline void *_dzalloc_array(struct domain *d, size_t size,
>> +   size_t align, size_t num)
>> +{
>> +return _dzalloc(d, size * num, align);
> No protection at all against the multiplication overflowing?

Well - xmalloc doesn't have any either.  But yes - both want some
compiler-aided overflow detection, rather than messing around with
arbitrary limits pretending to be an overflow check.

~Andrew

Re: [PATCH 3/4] xen/domctl: Introduce fault_ttl

[Andrew Cooper]

On 05/01/2021 16:39, Jan Beulich wrote:
> On 23.12.2020 17:34, Andrew Cooper wrote:
>> To inject a simulated resource failure, for testing purposes.
>>
>> Given a specific set of hypercall parameters, the failure is in a repeatable
>> position, for the currently booted Xen.  The exact position of failures is
>> highly dependent on the build of Xen, and hardware support.
> What about other kinds of resources, or ones only indirectly
> related to memory allocations (e.g. where we don't mean to
> associate them with the domain)?

I intend this for "any fail-able operation", not just plain memory
allocation.

It's merely that memory allocation is the simple first resource to go
after.  And after all, these 4 patches alone have already identified a
real bug in ARM's dom0less logic.

Perhaps what we actually want is a general "bool simulate_failure(d)"
which dalloc() and others can use.

>>  * I'm thinking of dropping handle from xen_domctl_createdomain because it's 
>> a
>>waste of valuable space.
> Looks entirely unrelated, but yes - as long as Xen itself has no
> consumer of the field. The more that there already is
> XEN_DOMCTL_setdomainhandle.

It's purely for pretty printing in 'q' and handing back to userspace for
xentop, et al.  Nothing in Xen acts meaningfully upon the value.

>> --- a/xen/common/dmalloc.c
>> +++ b/xen/common/dmalloc.c
>> @@ -10,7 +10,13 @@ void dfree(struct domain *d, void *ptr)
>>  
>>  void *_dzalloc(struct domain *d, size_t size, size_t align)
>>  {
>> -void *ptr = _xmalloc(size, align);
>> +void *ptr;
>> +
>> +if ( atomic_read(&d->fault_ttl) &&
>> + atomic_dec_and_test(&d->fault_ttl) )
>> +return NULL;
> Perhaps we want to introduce Linux'es atomic_add_unless()?

Possibly.  I definitely got caught out by the semantics of
atomic_dec_and_test() seeing as it has an implicit "!= 0".

~Andrew

RE: [PATCH v2 2/2] xen/arm: Add defensive barrier in get_cycles for Arm64

[Wei Chen]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Sent: 2021年1月14日 2:30
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Penny Zheng
> ; Jiamei Xie ; nd
> 
> Subject: Re: [PATCH v2 2/2] xen/arm: Add defensive barrier in get_cycles for
> Arm64
> 
> 
> 
> On 09/01/2021 12:16, Wei Chen wrote:
> > HI Julien,
> 
> Hi Wei,
> 
> >> -Original Message-
> >> From: Julien Grall 
> >> Sent: 2021年1月8日 19:56
> >> To: Wei Chen ; xen-devel@lists.xenproject.org;
> >> sstabell...@kernel.org
> >> Cc: Bertrand Marquis ; Penny Zheng
> >> ; Jiamei Xie ; nd
> >> 
> >> Subject: Re: [PATCH v2 2/2] xen/arm: Add defensive barrier in get_cycles 
> >> for
> >> Arm64
> >>
> >> Hi Wei,
> >>
> >> On 08/01/2021 06:21, Wei Chen wrote:
> >>> Per the discussion [1] on the mailing list, we'd better to
> >>> have a barrier after reading CNTPCT in get_cycles. If there
> >>> is not any barrier there. When get_cycles being used in some
> >>> seqlock critical context in the future, the seqlock can be
> >>> speculated potentially.
> >>>
> >>> We import Linux commit 75a19a0202db21638a1c2b424afb867e1f9a2376:
> >>>   arm64: arch_timer: Ensure counter register reads occur with seqlock
> held
> >>>
> >>>   When executing clock_gettime(), either in the vDSO or via a system 
> >>> call,
> >>>   we need to ensure that the read of the counter register occurs 
> >>> within
> >>>   the seqlock reader critical section. This ensures that updates to 
> >>> the
> >>>   clocksource parameters (e.g. the multiplier) are consistent with the
> >>>   counter value and therefore avoids the situation where time appears 
> >>> to
> >>>   go backwards across multiple reads.
> >>>
> >>>   Extend the vDSO logic so that the seqlock critical section covers 
> >>> the
> >>>   read of the counter register as well as accesses to the data page. 
> >>> Since
> >>>   reads of the counter system registers are not ordered by memory 
> >>> barrier
> >>>   instructions, introduce dependency ordering from the counter read 
> >>> to a
> >>>   subsequent memory access so that the seqlock memory barriers apply 
> >>> to
> >>>   the counter access in both the vDSO and the system call paths.
> >>>
> >>>   Cc: 
> >>>   Cc: Marc Zyngier 
> >>>   Tested-by: Vincenzo Frascino 
> >>>   Link: https://lore.kernel.org/linux-arm-
> >> kernel/alpine.deb.2.21.1902081950260.1...@nanos.tec.linutronix.de/
> >>>   Reported-by: Thomas Gleixner 
> >>>   Signed-off-by: Will Deacon 
> >>>
> >>> While we are not aware of such use in Xen, it would be best to add the
> >>> barrier to avoid any suprise.
> >>>
> >>> In order to reduce the impact of new barrier, we perfer to
> >>> use enforce order instead of ISB [2].
> >>>
> >>> Currently, enforce order is not applied to arm32 as this is
> >>> not done in Linux at the date of this patch. If this is done
> >>> in Linux it will need to be also done in Xen.
> >>>
> >>> [1] https://lists.xenproject.org/archives/html/xen-devel/2020-
> >> 12/msg00181.html
> >>> [2] https://lkml.org/lkml/2020/3/13/645
> >>>
> >>> Signed-off-by: Wei Chen 
> >>> ---
> >>> v1 -> v2:
> >>> 1. Update commit message to refer Linux commit.
> >>> 2. Change u64 to uint64_t
> >>> ---
> >>>xen/include/asm-arm/time.h | 43
> >> --
> >>>1 file changed, 41 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
> >>> index 5c4529ebb5..6b8fd839dd 100644
> >>> --- a/xen/include/asm-arm/time.h
> >>> +++ b/xen/include/asm-arm/time.h
> >>> @@ -11,9 +11,26 @@
> >>>
> >>>typedef uint64_t cycles_t;
> >>>
> >>> -static inline cycles_t get_cycles(void)
> >>> +/*
> >>> + * Ensure that reads of the counter are treated the same as memory reads
> >>> + * for the purposes of ordering by subsequent memory barriers.
> >>> + */
> >>> +#if defined(CONFIG_ARM_64)
> >>> +#define read_cntpct_enforce_ordering(val) do { \
> >>> +uint64_t tmp, _val = (val);\
> >>> +   \
> >>> +asm volatile(  \
> >>> +"eor %0, %1, %1\n" \
> >>> +"add %0, sp, %0\n" \
> >>> +"ldr xzr, [%0]"\
> >>> +: "=r" (tmp) : "r" (_val));\
> >>> +} while (0)
> >>> +#else
> >>> +#define read_cntpct_enforce_ordering(val) do {} while (0)
> >>> +#endif
> >>> +
> >>> +static inline cycles_t read_cntpct_stable(void)
> >>
> >> OOI, is there any particular reason to create a new helper?
> >>
> >
> > Yes, I try to reduce the #if defined(CONFIG_ARM_64) chunks.
> 
> Hmmm... There is no #ifdef chunk in read_cntpct_stable(). Did I miss
> anything?

No, It was I who misunderstood your comments.

> 
> > I think
> > if we introduce an empty helper for Arm32, we can reduce the other
> > chunk inside get_cycles. In addition, if we 

Re: [PATCH 3/3] objtool: Support stack layout changes in alternatives

[Josh Poimboeuf]

On Fri, Jan 08, 2021 at 09:15:43AM +0100, Miroslav Benes wrote:
> > That comment is indeed now obsolete.  I can squash something like so:
> > 
> > diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> > index 81d56fdef1c3..ce67437aaf3f 100644
> > --- a/tools/objtool/check.c
> > +++ b/tools/objtool/check.c
> > @@ -958,21 +958,8 @@ static int add_call_destinations(struct objtool_file 
> > *file)
> >  }
> >  
> >  /*
> > - * The .alternatives section requires some extra special care, over and 
> > above
> > - * what other special sections require:
> > - *
> > - * 1. Because alternatives are patched in-place, we need to insert a fake 
> > jump
> > - *instruction at the end so that validate_branch() skips all the 
> > original
> > - *replaced instructions when validating the new instruction path.
> > - *
> > - * 2. An added wrinkle is that the new instruction length might be zero.  
> > In
> > - *that case the old instructions are replaced with noops.  We simulate 
> > that
> > - *by creating a fake jump as the only new instruction.
> > - *
> > - * 3. In some cases, the alternative section includes an instruction which
> > - *conditionally jumps to the _end_ of the entry.  We have to modify 
> > these
> > - *jumps' destinations to point back to .text rather than the end of the
> > - *entry in .altinstr_replacement.
> > + * The .alternatives section requires some extra special care over and 
> > above
> > + * other special sections because alternatives are patched in place.
> >   */
> >  static int handle_group_alt(struct objtool_file *file,
> > struct special_alt *special_alt,
> 
> Looks good to me.

Thanks, I squashed this in.

If there are no objections, I'll go ahead and merge this set in -tip.
It doesn't have any direct dependencies on the Juergen's changes, and it
would be nice to have some of these changes in-tree, especially the fake
jump removal.

-- 
Josh

[qemu-mainline test] 158406: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
 test-amd64-amd64-xl-qcow2   21 guest-start/debian.repeat fail REGR. vs. 152631
 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 152631

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 152631
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 152631
 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail  like 152631
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631
 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-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   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-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 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-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-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-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-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass

version targeted for testing:
 qemuuf8e1d8852e393b3fd524fb005e38590063d99bc0
baseline version:
 qemuu1d806cef0e38b5db8347a8e12f214d543204a314

Last test of basis   152631  2020-08-20 09:07:46 Z  146 days
Failing since152659  2020-08-21 14:07:39 Z  145 days  301 attempts
Testing same since   158396  2021-01-13 04:01:49 Z0 days2 attempts


344 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm

Re: [PATCH v2 0/7] Rid W=1 warnings in Ethernet

[Jakub Kicinski]

On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
> Resending the stragglers again.   
>
> 
> This set is part of a larger effort attempting to clean-up W=1
>
> kernel builds, which are currently overwhelmingly riddled with
>
> niggly little warnings.   
>
>   
>
> v2:   
>
>  - Squashed IBM patches   
>
>  - Fixed real issue in SMSC
>  - Added Andrew's Reviewed-by tags on remainder

Does not apply, please rebase on net-next/master.

RE: [PATCH V4 00/24] IOREQ feature (+ virtio-mmio) on Arm

[Wei Chen]

Hi Oleksandr,

I have tested this series with latest master and staging branches. 
The virtio function works well for Arm as v3.

For latest staging branch, it needs a tiny rebase for:
0011 xen/mm: Make x86's XENMEM_resource_ioreq_server handling common
As staging branch changes rapidly, I had done it manually and done the test.
It should not affect review.

Tested-by: Wei Chen 

> -Original Message-
> From: Xen-devel  On Behalf Of
> Oleksandr Tyshchenko
> Sent: 2021年1月13日 5:52
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Paul Durrant
> ; Jan Beulich ; Andrew Cooper
> ; Roger Pau Monné ;
> Wei Liu ; Julien Grall ; George Dunlap
> ; Ian Jackson ; Julien Grall
> ; Stefano Stabellini ; Jun Nakajima
> ; Kevin Tian ; Tim Deegan
> ; Daniel De Graaf ; Volodymyr
> Babchuk ; Anthony PERARD
> ; Bertrand Marquis ;
> Wei Chen ; Kaly Xin ; Artem
> Mygaiev ; Alex Bennée 
> Subject: [PATCH V4 00/24] IOREQ feature (+ virtio-mmio) on Arm
> 
> From: Oleksandr Tyshchenko 
> 
> Hello all.
> 
> The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
> You can find an initial discussion at [1] and RFC-V3 series at [2]-[5].
> Xen on Arm requires some implementation to forward guest MMIO access to a
> device
> model in order to implement virtio-mmio backend or even mediator outside of
> hypervisor.
> As Xen on x86 already contains required support this series tries to make it
> common
> and introduce Arm specific bits plus some new functionality. Patch series is
> based on
> Julien's PoC "xen/arm: Add support for Guest IO forwarding to a device
> emulator".
> Besides splitting existing IOREQ/DM support and introducing Arm side, the 
> series
> also includes virtio-mmio related changes (last 2 patches for toolstack)
> for the reviewers to be able to see how the whole picture could look like
> and give it a try.
> 
> According to the initial/subsequent discussions there are a few open
> questions/concerns regarding security, performance in VirtIO solution:
> 1. virtio-mmio vs virtio-pci, SPI vs MSI, or even a composition of 
> virtio-mmio +
> MSI,
>different use-cases require different transport...
> 2. virtio backend is able to access all guest memory, some kind of protection
>is needed: 'virtio-iommu in Xen' vs 'pre-shared-memory & memcpys in guest',
> etc
>(for the first two Alex have provided valuable input at [6])
> 3. interface between toolstack and 'out-of-qemu' virtio backend, avoid using
>Xenstore in virtio backend if possible. Also, there is a desire to make 
> VirtIO
>backend hypervisor-agnostic.
> 4. a lot of 'foreing mapping' could lead to the memory exhaustion at the host
> side,
>as we are stealing the page from host memory in order to map the guest 
> page.
>Julien has some idea regarding that.
> 5. Julien also has some ideas how to optimize the IOREQ code:
>5.1 vcpu_ioreq_handle_completion (former handle_hvm_io_completion)
> which is called in
>an hotpath on Arm (everytime we are re-entering to the guest):
>Ideally, vcpu_ioreq_handle_completion should be a NOP (at max a few
> instructions)
>if there is nothing to do (if we don't have I/O forwarded to an IOREQ 
> server).
>Maybe we want to introduce a per-vCPU flag indicating if an I/O has 
> been
>forwarded to an IOREQ server. This would allow us to bypass most of the
> function
>if there is nothing to do.
>5.2 The current way to handle MMIO is the following:
>- Pause the vCPU
>- Forward the access to the backend domain
>- Schedule the backend domain
>- Wait for the access to be handled
>- Unpause the vCPU
>The sequence is going to be fairly expensive on Xen.
>It might be possible to optimize the ACK and avoid to wait for the 
> backend
>to handle the access.
> 
> Looks like all of them are valid and worth considering, but the first thing
> which we need on Arm is a mechanism to forward guest IO to a device emulator,
> so let's focus on it in the first place.
> 
> ***
> 
> There are a lot of changes since RFC series, almost all TODOs were resolved on
> Arm,
> Arm code was improved and hardened, common IOREQ/DM code became really
> arch-agnostic
> (without HVM-ism), the "legacy" mechanism of mapping magic pages for the
> IOREQ servers
> was left x86 specific, etc. Also patch that makes DM code public was reworked
> to have
> the top level dm-op handling arch-specific and call into ioreq_server_dm_op()
> for otherwise unhandled ops.
> But one TODO still remains which is "PIO handling" on Arm.
> The "PIO handling" TODO is expected to left unaddressed for the current 
> series.
> It is not an big issue for now while Xen doesn't have support for vPCI on Arm.
> On Arm64 they are only used for PCI IO Bar and we would probably want to
> expose
> them to emulator as PIO access to make a DM completely arch-agnostic. So
> "PIO handling"
> should be implemented when we add support for

[xen-unstable-smoke test] 158412: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 15 migrate-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-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0293fd24bbaa2c4fa0acbe2abcd2d41b96ecd7e1
baseline version:
 xen  896128e9352327c4ff2b5c0c6cfa3856e45e2ca3

Last test of basis   158408  2021-01-13 20:00:29 Z0 days
Testing same since   158412  2021-01-14 01:00:28 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   896128e935..0293fd24bb  0293fd24bbaa2c4fa0acbe2abcd2d41b96ecd7e1 -> smoke

RE: [PATCH V4 11/24] xen/mm: Make x86's XENMEM_resource_ioreq_server handling common

[Wei Chen]

Hi Oleksandr,

> -Original Message-
> From: Xen-devel  On Behalf Of
> Oleksandr Tyshchenko
> Sent: 2021年1月13日 5:52
> To: xen-devel@lists.xenproject.org
> Cc: Julien Grall ; Jan Beulich ;
> Andrew Cooper ; Roger Pau Monné
> ; Wei Liu ; George Dunlap
> ; Ian Jackson ; Julien Grall
> ; Stefano Stabellini ; Volodymyr
> Babchuk ; Oleksandr Tyshchenko
> 
> Subject: [PATCH V4 11/24] xen/mm: Make x86's
> XENMEM_resource_ioreq_server handling common
> 
> From: Julien Grall 
> 
> As x86 implementation of XENMEM_resource_ioreq_server can be
> re-used on Arm later on, this patch makes it common and removes
> arch_acquire_resource as unneeded.
> 
> Also re-order #include-s alphabetically.
> 
> This support is going to be used on Arm to be able run device
> emulator outside of Xen hypervisor.
> 
> Signed-off-by: Julien Grall 
> Signed-off-by: Oleksandr Tyshchenko 
> Reviewed-by: Jan Beulich 
> [On Arm only]
> Tested-by: Wei Chen 
> 
> ---
> Please note, this is a split/cleanup/hardening of Julien's PoC:
> "Add support for Guest IO forwarding to a device emulator"
> 
> Changes RFC -> V1:
>- no changes
> 
> Changes V1 -> V2:
>- update the author of a patch
> 
> Changes V2 -> V3:
>- don't wrap #include 
>- limit the number of #ifdef-s
>- re-order #include-s alphabetically
> 
> Changes V3 -> V4:
>- rebase
>- Add Jan's R-b
> ---
>  xen/arch/x86/mm.c| 44 -
>  xen/common/memory.c  | 63
> +++-
>  xen/include/asm-arm/mm.h |  8 --
>  xen/include/asm-x86/mm.h |  4 ---
>  4 files changed, 51 insertions(+), 68 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index f6e128e..54ac398 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4587,50 +4587,6 @@ static int handle_iomem_range(unsigned long s,
> unsigned long e, void *p)
>  return err || s > e ? err : _handle_iomem_range(s, e, p);
>  }
> 
> -int arch_acquire_resource(struct domain *d, unsigned int type,
> -  unsigned int id, unsigned long frame,
> -  unsigned int nr_frames, xen_pfn_t mfn_list[])
> -{
> -int rc;
> -
> -switch ( type )
> -{
> -#ifdef CONFIG_HVM
> -case XENMEM_resource_ioreq_server:
> -{
> -ioservid_t ioservid = id;
> -unsigned int i;
> -
> -rc = -EINVAL;
> -if ( !is_hvm_domain(d) )
> -break;
> -
> -if ( id != (unsigned int)ioservid )
> -break;
> -
> -rc = 0;
> -for ( i = 0; i < nr_frames; i++ )
> -{
> -mfn_t mfn;
> -
> -rc = hvm_get_ioreq_server_frame(d, id, frame + i, &mfn);
> -if ( rc )
> -break;
> -
> -mfn_list[i] = mfn_x(mfn);
> -}
> -break;
> -}
> -#endif
> -
> -default:
> -rc = -EOPNOTSUPP;
> -break;
> -}
> -
> -return rc;
> -}
> -
>  long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
>  {
>  int rc;
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index b21b6c4..7e560b5 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -8,22 +8,23 @@
>   */
> 
>  #include 
> -#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1090,6 +1091,40 @@ static int acquire_grant_table(struct domain *d,
> unsigned int id,
>  return 0;
>  }
> 
> +static int acquire_ioreq_server(struct domain *d,
> +unsigned int id,
> +unsigned long frame,
> +unsigned int nr_frames,
> +xen_pfn_t mfn_list[])
> +{
> +#ifdef CONFIG_IOREQ_SERVER
> +ioservid_t ioservid = id;
> +unsigned int i;
> +int rc;
> +
> +if ( !is_hvm_domain(d) )
> +return -EINVAL;
> +
> +if ( id != (unsigned int)ioservid )
> +return -EINVAL;
> +
> +for ( i = 0; i < nr_frames; i++ )
> +{
> +mfn_t mfn;
> +
> +rc = hvm_get_ioreq_server_frame(d, id, frame + i, &mfn);
> +if ( rc )
> +return rc;
> +
> +mfn_list[i] = mfn_x(mfn);
> +}
> +
> +return 0;
> +#else
> +return -EOPNOTSUPP;
> +#endif
> +}
> +
>  static int acquire_resource(
>  XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg)
>  {
> @@ -1148,9 +1183,13 @@ static int acquire_resource(
>   mfn_list);
>  break;
> 
> +case XENMEM_resource_ioreq_server:
> +rc = acquire_ioreq_server(d, xmar.id, xmar.frame, xmar.nr_frames,
> +  mfn_list);
> +break

[xen-unstable test] 158409: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-thunderx  8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-examine  8 reboot   fail REGR. vs. 158290
 test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-xl-xsm   8 xen-boot fail REGR. vs. 158290
 test-arm64-arm64-xl-credit2   8 xen-boot fail REGR. vs. 158290

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-localmigrate/x10 fail pass in 
158399
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 158399
 test-armhf-armhf-libvirt-raw 13 guest-startfail pass in 158399
 test-armhf-armhf-xl-vhd  20 leak-check/check   fail pass in 158399

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail in 158399 like 
158290
 test-armhf-armhf-libvirt-raw 14 migrate-support-check fail in 158399 never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158290
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 158290
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 158290
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 158290
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 158290
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 158290
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 158290
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 158290
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 158290
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 158290
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-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-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-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-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-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-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-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-armhf-armhf-libvirt 15 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-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  414be7b66349e7dca42bc1fd47c2b2f5b2d27432
baseline version:
 xen  7ba2ab495be54f608cb47440e1497b2795bd301a

Last test of basis   158290  2021-01-09 01:51:29 Z5 days
Failing since158296  2021-01-09 11:08:42 Z4 days9 attempts
Testing same since   158399  2021-01-13 05:44:30 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bertrand Marquis 
  Jan Beulich 
  Julien Grall 
  Manuel Bouyer 
  Marek Marczykowski-Górecki 
  Olaf Hering 
  Oleksandr Tyshchenko 

[libvirt test] 158415: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-armhf-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  0a6cb05e953d315b7a05103d707cff4d36221211
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  188 days
Failing since151818  2020-07-11 04:18:52 Z  187 days  182 attempts
Testing same since   158415  2021-01-14 04:21:21 Z0 days1 attempts


People who touched revisions under test:
  Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Andika Triwidada 
  Andrea Bolognani 
  Balázs Meskó 
  Barrett Schonefeld 
  Bastien Orivel 
  Bihong Yu 
  Binfeng Wu 
  Boris Fiuczynski 
  Brian Turek 
  Christian Ehrhardt 
  Christian Schoenebeck 
  Cole Robinson 
  Collin Walling 
  Cornelia Huck 
  Côme Borsoi 
  Daniel Henrique Barboza 
  Daniel Letai 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  Eiichi Tsukata 
  Erik Skultety 
  Fabian Affolter 
  Fabian Freyer 
  Fangge Jin 
  Farhan Ali 
  Fedora Weblate Translation 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Ian Wienand 
  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 
  Laine Stump 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Lin Ma 
  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 
  Neal Gompa 
  Nick Shyrokovskiy 
  Nickys Music Group 
  Nico Pache 
  Nikolay Shirokovskiy 
  Olaf Hering 
  Olesya Gerasimenko 
  Orion Poplawski 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  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 
  Shalini Chellathurai Saroja 
  Shaojun Yang 
  Shi Lei 
  Simon Gaiser 
  Stefan Bader 
  Stefan Berger 
  Szymon Scholz 
  Thomas Huth 
  Tim Wiederhake 
  Tomáš Golembiovský 
  Tomáš Janoušek 
  Tuguoyi 
  Wang Xin 
  Weblate 
  Yang Hang 
  Yanqiu Zhang 
  Yi Li 
  Yi Wang 
  Yuri Chornoivan 
  Zheng Chuan 
  zhenwei pi 
  Zhenyu Zheng 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvops