[linux-5.4 test] 173461: tolerable FAIL - PUSHED

2022-10-07 Thread osstest service owner 
flight 173461 linux-5.4 real [real]
flight 173465 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173461/
http://logs.test-lab.xenproject.org/osstest/logs/173465/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd  13 guest-start fail pass in 173465-retest

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

[ovmf test] 173463: all pass - PUSHED

2022-10-07 Thread osstest service owner 
flight 173463 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173463/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 406ad0582a3df7af498ec4f0adee1a95ceeae64f
baseline version:
 ovmf 5ff7d712d489a4fba4e8b0f609218e33c1208e52

Last test of basis   173449  2022-10-06 17:40:27 Z1 days
Testing same since   173463  2022-10-07 18:42:36 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   5ff7d712d4..406ad0582a  406ad0582a3df7af498ec4f0adee1a95ceeae64f -> 
xen-tested-master

[xen-unstable test] 173459: tolerable FAIL - PUSHED

2022-10-07 Thread osstest service owner 
flight 173459 xen-unstable real [real]
flight 173464 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173459/
http://logs.test-lab.xenproject.org/osstest/logs/173464/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-examine  8 reboot  fail pass in 173464-retest

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

RE: [PATCH] argo: Remove reachable ASSERT_UNREACHABLE

2022-10-07 Thread Henry Wang 
Hi Andrew and Jason,

> -Original Message-
> From: Andrew Cooper 
> Subject: Re: [PATCH] argo: Remove reachable ASSERT_UNREACHABLE
> 
> On 07/10/2022 20:31, Jason Andryuk wrote:
> > I observed this ASSERT_UNREACHABLE in partner_rings_remove
> consistently
> > trip.  It was in OpenXT with the viptables patch applied.
> >
> > dom10 shuts down.
> > dom7 is REJECTED sending to dom10.
> > dom7 shuts down and this ASSERT trips for dom10.
> >
> > The argo_send_info has a domid, but there is no refcount taken on
> > the domain.  Therefore it's not appropriate to ASSERT that the domain
> > can be looked up via domid.  Replace with a debug message.
> >
> > Signed-off-by: Jason Andryuk 
> 
> We're into the 4.17 release process now.  A bugfix like this obviously
> should be considered, but will need approval from the release manager.
> CC Henry.

Andrew: Thanks for the information!

Jason: Would you mind adding a "Fixes:" tag following the rule described
in [1]? Thanks very much! With this tag and proper review/ack from
maintainers:

Release-acked-by: Henry Wang 

[1] https://xenbits.xen.org/docs/unstable/process/sending-patches.html#fixes

Kind regards,
Henry

> 
> ~Andrew
> 
> > ---
> >  xen/common/argo.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/common/argo.c b/xen/common/argo.c
> > index 748b8714d6..973e1e9956 100644
> > --- a/xen/common/argo.c
> > +++ b/xen/common/argo.c
> > @@ -1298,7 +1298,8 @@ partner_rings_remove(struct domain *src_d)
> >  ASSERT_UNREACHABLE();
> >  }
> >  else
> > -ASSERT_UNREACHABLE();
> > +argo_dprintk("%pd has entry for stale partner domid %d\n",
> > + src_d, send_info->id.domain_id);
> >
> >  if ( dst_d )
> >  rcu_unlock_domain(dst_d);

[PATCH v3 3/4] add SPDX to arch/arm/*.c

2022-10-07 Thread Stefano Stabellini 
From: Stefano Stabellini 

Add SPDX license information to all the *.c files under arch/arm.

Signed-off-by: Stefano Stabellini 
---
Changes in v3:
- change xen/arch/arm/domain_page.c to GPL-2.0-or-later

Changes in v2:
- use /* */
- actually check use the right license
- remove stale copyright info from top of the file header
---
 xen/arch/arm/alternative.c| 13 +
 xen/arch/arm/bootfdt.c|  5 +
 xen/arch/arm/cpuerrata.c  |  1 +
 xen/arch/arm/cpufeature.c | 13 +
 xen/arch/arm/decode.c | 11 +--
 xen/arch/arm/device.c | 11 +--
 xen/arch/arm/dm.c | 13 +
 xen/arch/arm/domain.c | 12 +---
 xen/arch/arm/domain_build.c   |  1 +
 xen/arch/arm/domain_page.c|  1 +
 xen/arch/arm/domctl.c |  1 +
 xen/arch/arm/early_printk.c   |  5 +
 xen/arch/arm/gic-v2.c | 11 +--
 xen/arch/arm/gic-v3-its.c | 13 +
 xen/arch/arm/gic-v3-lpi.c | 13 +
 xen/arch/arm/gic-v3.c | 11 +--
 xen/arch/arm/gic-vgic.c   | 11 +--
 xen/arch/arm/gic.c| 11 +--
 xen/arch/arm/guest_atomics.c  | 13 +
 xen/arch/arm/guest_walk.c | 13 +
 xen/arch/arm/guestcopy.c  |  1 +
 xen/arch/arm/hvm.c| 13 +
 xen/arch/arm/io.c | 11 +--
 xen/arch/arm/ioreq.c  | 13 +
 xen/arch/arm/irq.c| 11 +--
 xen/arch/arm/kernel.c |  1 +
 xen/arch/arm/livepatch.c  |  1 +
 xen/arch/arm/mem_access.c | 13 +
 xen/arch/arm/mm.c | 11 +--
 xen/arch/arm/monitor.c| 13 +
 xen/arch/arm/p2m.c|  1 +
 xen/arch/arm/percpu.c |  1 +
 xen/arch/arm/physdev.c|  1 +
 xen/arch/arm/platform.c   | 11 +--
 xen/arch/arm/platform_hypercall.c |  1 +
 xen/arch/arm/processor.c  | 11 +--
 xen/arch/arm/psci.c   | 11 +--
 xen/arch/arm/setup.c  | 11 +--
 xen/arch/arm/shutdown.c   |  1 +
 xen/arch/arm/smp.c|  1 +
 xen/arch/arm/smpboot.c| 11 +--
 xen/arch/arm/sysctl.c |  1 +
 xen/arch/arm/time.c   | 11 +--
 xen/arch/arm/traps.c  | 11 +--
 xen/arch/arm/vcpreg.c | 11 +--
 xen/arch/arm/vgic-v2.c| 11 +--
 xen/arch/arm/vgic-v3-its.c| 13 +
 xen/arch/arm/vgic-v3.c| 11 +--
 xen/arch/arm/vgic.c   | 11 +--
 xen/arch/arm/vm_event.c   | 13 +
 xen/arch/arm/vpci.c   | 11 +--
 xen/arch/arm/vpl011.c | 13 +
 xen/arch/arm/vpsci.c  | 13 +
 xen/arch/arm/vsmc.c   | 10 +-
 xen/arch/arm/vtimer.c | 11 +--
 xen/arch/arm/vuart.c  | 11 +--
 56 files changed, 56 insertions(+), 438 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index f03cd943c6..f00e3b9b3c 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -1,20 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * alternative runtime patching
  * inspired by the x86 version
  *
  * Copyright (C) 2014-2016 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
  */
 
 #include 
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 6014c0f852..0085c28d74 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -1,11 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Early Device Tree
  *
  * Copyright (C) 2012-2014 Citrix Systems, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 #include 
 #include 
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index ae649d16ef..99bd4a7d38 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 62d5e1770a..c4ec38bb25 100644

[PATCH v3 2/4] Add licenses under LICENSES

2022-10-07 Thread Stefano Stabellini 
From: Stefano Stabellini 

Add the individual licenses under a new top-level directory named
"LICENSES". Each license file includes its related SPDX tags.

Signed-off-by: Stefano Stabellini 
---
 LICENSES/BSD-2-Clause   |  32 +++
 LICENSES/BSD-3-Clause   |  36 +++
 LICENSES/BSD-3-Clause-Clear |  41 +++
 LICENSES/GPL-2.0| 359 +
 LICENSES/LGPL-2.0   | 487 ++
 LICENSES/LGPL-2.1   | 503 
 LICENSES/MIT|  30 +++
 7 files changed, 1488 insertions(+)
 create mode 100644 LICENSES/BSD-2-Clause
 create mode 100644 LICENSES/BSD-3-Clause
 create mode 100644 LICENSES/BSD-3-Clause-Clear
 create mode 100644 LICENSES/GPL-2.0
 create mode 100644 LICENSES/LGPL-2.0
 create mode 100644 LICENSES/LGPL-2.1
 create mode 100644 LICENSES/MIT

diff --git a/LICENSES/BSD-2-Clause b/LICENSES/BSD-2-Clause
new file mode 100644
index 00..da366e2ce5
--- /dev/null
+++ b/LICENSES/BSD-2-Clause
@@ -0,0 +1,32 @@
+Valid-License-Identifier: BSD-2-Clause
+SPDX-URL: https://spdx.org/licenses/BSD-2-Clause.html
+Usage-Guide:
+  To use the BSD 2-clause "Simplified" License put the following SPDX
+  tag/value pair into a comment according to the placement guidelines in
+  the licensing rules documentation:
+SPDX-License-Identifier: BSD-2-Clause
+License-Text:
+
+Copyright (c)   . All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice,
+   this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
diff --git a/LICENSES/BSD-3-Clause b/LICENSES/BSD-3-Clause
new file mode 100644
index 00..34c7f057c8
--- /dev/null
+++ b/LICENSES/BSD-3-Clause
@@ -0,0 +1,36 @@
+Valid-License-Identifier: BSD-3-Clause
+SPDX-URL: https://spdx.org/licenses/BSD-3-Clause.html
+Usage-Guide:
+  To use the BSD 3-clause "New" or "Revised" License put the following SPDX
+  tag/value pair into a comment according to the placement guidelines in
+  the licensing rules documentation:
+SPDX-License-Identifier: BSD-3-Clause
+License-Text:
+
+Copyright (c)   . All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice,
+   this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from this
+   software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
diff --git a/LICENSES/BSD-3-Clause-Clear b/LICENSES/BSD-3-Clause-Clear
new file mode 100644
index 00..e53b56092b
--- /dev/null
+++ b/LICENSES/BSD-3-Clause-Clear
@@ -0,0 +1,41 @@
+Valid-License-Identifier: BSD-3-Clause-Clear
+SPDX-URL:

[PATCH v3 4/4] Remove extra copies of licenses and license headers

2022-10-07 Thread Stefano Stabellini 
From: Stefano Stabellini 

Remove the extra copy of the GPL license and license copyright headers
from CONTRIBUTING and the top-level COPYING.

Mention of the LICENSES/ directory and also mention the SPDX tag.

SPDX support is still in progress and COPYING files in subdirectories
still need to be updated.

Signed-off-by: Stefano Stabellini 
---
Patch new in v3
---
 CONTRIBUTING | 150 ++
 COPYING  | 351 +--
 2 files changed, 17 insertions(+), 484 deletions(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 6ec146baf0..7b6b03fb96 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -19,10 +19,6 @@ Most notably:
  - tools/xl   : LGPL v2.1
  - xen/include/public : MIT license
 
-The COMMON COPYRIGHT NOTICES section of this document contains
-sample copyright notices for the most common licenses used within
-this repository.
-
 When creating new components, new files, or importing code please follow
 the conventions outlined below. As a general rule, whenever code using a
 license other than GPLv2 is introduced, attention must be drawn to the
@@ -32,20 +28,22 @@ deviation. Any new code must be GPLv2 compatible.
 New components
 --
 
-When creating new components and directories that contain a
-significant amount of files that are licensed under licenses other
-than GPLv2 or the license specified in the COPYING file, please
-create a new COPYING file in that directory containing a copy of the
-license text and a rationale for using a different license. This helps
-ensure that the license of this new component/directory is maintained
-consistently with the original intention.
+When creating new components and directories that contain a significant
+amount of files that are licensed under licenses other than GPLv2,
+please create a new COPYING file in that directory with the rationale
+for using a different license. This helps ensure that the license of
+this new component/directory is maintained consistently with the
+original intention.
 
 New files
 -
 
-If specific files that differ from the license in a directory are introduced,
-exceptions should be highlighted and discussed in the commit message or cover
-letter introducing the file.
+New files should start with a single-line SPDX comment to express the
+license. The following comment and license are recommended:
+
+/* SPDX-License-Identifier: GPL-2.0 */
+
+See LICENSES/ for a list of licenses and SPDX tags currently used.
 
 Importing code
 --
@@ -105,127 +103,3 @@ For more information on contributing to this repository, 
see
  - https://wiki.xenproject.org/wiki/Category:Developers
 
 
-COMMON COPYRIGHT NOTICES
-
-
-The following section contains sample copyright notice for the most
-common licenses used within the Xen Project that is consistent with the
-projects coding standards.
-
-GPL v2 License
---
-
-/*
- * 
- *
- * 
- *
- * Copyright (C)   
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms and conditions of the GNU General Public
- * License, version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public
- * License along with this program; If not, see .
- */
-
-
-LGPL v2.1 License
--
-
-/*
- * 
- *
- * 
- *
- * Copyright (C)   
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License, version 2.1, 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 .
- */
-
-BSD-Modified License (also known as BSD-3-Clause)
--
-
-/*
- * 
- *
- * 
- *
- * Copyright (C)   
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- *   1. Redistributions of source code must retain the above copyright
- *  notice, this list of conditions and the following disclaimer.
- *   2. Redistributions in binary form must reproduce the above
- *  copyright notice, this list of conditions and the following
- *  disclaimer in the documentation and/or other materials

[PATCH v3 1/4] Add SPDX to CODING_STYLE

2022-10-07 Thread Stefano Stabellini 
From: Stefano Stabellini 

Signed-off-by: Stefano Stabellini 
---
 CODING_STYLE | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/CODING_STYLE b/CODING_STYLE
index 3386ee1d90..5faf274b3a 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -14,6 +14,16 @@ explicitly (e.g. tools/libxl/CODING_STYLE) but often 
implicitly (Linux
 coding style is fairly common). In general you should copy the style
 of the surrounding code. If you are unsure please ask.
 
+SPDX
+
+
+New files should start with a single-line SPDX comment to express the
+license, e.g.:
+
+/* SPDX-License-Identifier: GPL-2.0 */
+
+See LICENSES/ for a list of licenses and SPDX tags currently used.
+
 MISRA C
 ---
 
-- 
2.25.1

[PATCH v3 0/4] introduce SPDX

2022-10-07 Thread Stefano Stabellini 
Hi all,

This small series introduces SPDX tags to Xen:

1) add a mention to SPDX in CODING_STYLE
2) add a LICENSES directory with licenses and SPDX tags
3) adds the SPDX single-line comment to arch/arm/*.c

Note that arch/arm/*.c is just a start. Also, to make the changes as
mechanical as possible I restricted myself to:
- adding the single-line comment at the top of the file
- removing the copyright lines (when present) from the top of the file
  header

I purposedly restrained myself to do other cleanups to the headers: this
series already touches many files and I prefer to keep these changes as
mechanical as possible. Further improvements (style improvement,
removing what's left of the header, removing copyright lines, etc.) can
be done with subsequent patches more easily.

License changes are not intentional.

Cheers,

Stefano

Re: [PATCH v1 0/4] Yocto Gitlab CI

2022-10-07 Thread Stefano Stabellini 
On Wed, 24 Aug 2022, Bertrand Marquis wrote:
> This patch series is a first attempt to check if we could use Yocto in
> gitlab ci to build and run xen on qemu for arm, arm64 and x86.
> 
> The first patch is making sure build-yocto.sh is not catched by
> gitignore.
> 
> The second patch is creating a container with all elements required to
> build Yocto, a checkout of the yocto layers required and an helper
> script to build and run xen on qemu with yocto.
> 
> The third patch is creating containers with a first build of yocto done
> so that susbsequent build with those containers would only rebuild what
> was changed and take the rest from the cache.
> 
> The fourth patch is adding a way to easily clean locally created
> containers.
> 
> This is is mainly for discussion and sharing as there are still some
> issues/problem to solve:
> - building the qemu* containers can take several hours depending on the
>   network bandwith and computing power of the machine where those are
>   created
> - produced containers containing the cache have a size between 8 and
>   12GB depending on the architecture. We might need to store the build
>   cache somewhere else to reduce the size. If we choose to have one
>   single image, the needed size is around 20GB and we need up to 40GB
>   during the build, which is why I splitted them.
> - during the build and run, we use a bit more then 20GB of disk which is
>   over the allowed size in gitlab
> 

So I tried to build one of the build containers on my x86 workstation
with the following:

  make yocto/kirkstone-qemuarm64

but I get an error from the build:

  21:30:20 build qemuarm64: Error
  22:00:38 run qemuarm64: Error
  22:00:41 Build Complete (2 errors)
  The command '/bin/sh -c /home/$USER_NAME/bin/build-yocto.sh $target' returned 
a non-zero code: 2

Anyone else is having a better luck than me?


I don't think it is a problem if it takes a long time to build the build
containers because they are not built often and they are not built as
part of the gitlab-ci runs.

The issue could be the resulting container size. I wasn't aware of a
limit in gitlab -- I would like to try if there is a way around the
limit (either by changing a setting, or potentially switching to a
premium account.) However I need to be able to complete a container
build first :-)

How did you find out about the 20 GB limit? I couldn't find it in the
docs. The only info I could find states that there is no hard limit on
registry.gitlab.com.

Cheers,

Stefano

Re: [PATCH] xen: Kconfig: Fix spelling mistake "Maxmium" -> "Maximum"

2022-10-07 Thread Stefano Stabellini 
On Fri, 7 Oct 2022, Colin Ian King wrote:
> There is a spelling mistake in a Kconfig description. Fix it.
> 
> Signed-off-by: Colin Ian King 

Acked-by: Stefano Stabellini 


> ---
>  drivers/xen/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index a65bd92121a5..d5d7c402b651 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -56,7 +56,7 @@ config XEN_MEMORY_HOTPLUG_LIMIT
>   depends on XEN_HAVE_PVMMU
>   depends on MEMORY_HOTPLUG
>   help
> -   Maxmium amount of memory (in GiB) that a PV guest can be
> +   Maximum amount of memory (in GiB) that a PV guest can be
> expanded to when using memory hotplug.
>  
> A PV guest can have more memory than this limit if is
> -- 
> 2.37.3
>

[PATCH] xen: Kconfig: Fix spelling mistake "Maxmium" -> "Maximum"

2022-10-07 Thread Colin Ian King 
There is a spelling mistake in a Kconfig description. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/xen/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a65bd92121a5..d5d7c402b651 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -56,7 +56,7 @@ config XEN_MEMORY_HOTPLUG_LIMIT
depends on XEN_HAVE_PVMMU
depends on MEMORY_HOTPLUG
help
- Maxmium amount of memory (in GiB) that a PV guest can be
+ Maximum amount of memory (in GiB) that a PV guest can be
  expanded to when using memory hotplug.
 
  A PV guest can have more memory than this limit if is
-- 
2.37.3

Re: [PATCH] ImageBuilder: Add support for 64-bit addresses

2022-10-07 Thread Stefano Stabellini 
On Fri, 7 Oct 2022, Michal Orzel wrote:
> Hi Stefano,
> 
> On 07/10/2022 00:34, Stefano Stabellini wrote:
> > 
> > 
> > +xen-devel
> > 
> > On Thu, 6 Oct 2022, Michal Orzel wrote:
> >> At the moment, ImageBuilder assumes that all addresses/sizes are
> >> 32-bit max. It sets #{address,size}-cells to 0x2 and puts 0x0 as the
> >> value for the first cell. Because of that, we cannot specify MEMORY_START
> >> and MEMORY_END to be above 32-bits (e.g. to place the images in the
> >> upper memory bank).
> >>
> >> Add support to properly handle 64-bit addresses:
> >>  - add function split_into_halves to split the value passed as a first
> >>argument into upper and lower halves. These are then set as values for
> >>variables passed respetively as the second and third argument,
> >>  - whenever there is a variable storing the full 64-bit number with
> >>"addr" or "size" in name, introduce two additional variables with
> >>"addr1,addr2"/"size1,size2" in name to store the halves. These are
> >>then used to properly set cells.
> >>
> >> Signed-off-by: Michal Orzel 
> >>
> >> ---
> >>  scripts/uboot-script-gen | 60 +++-
> >>  1 file changed, 53 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
> >> index 16269f02f1e7..4c6525a910f3 100755
> >> --- a/scripts/uboot-script-gen
> >> +++ b/scripts/uboot-script-gen
> >> @@ -25,6 +25,14 @@ function dt_mknode()
> >>  fi
> >>  }
> >>
> >> +# Usage:
> >> +# split_into_halves   
> >> 
> >> +function split_into_halves()
> >> +{
> >> +eval "$2=$(printf "0x%X\n" $(($1 >> 32)))"
> >> +eval "$3=$(printf "0x%X\n" $(($1 & 0x)))"
> >> +}
> > 
> > I know it is the same thing, but I would prefer the following version
> > because it makes it easier to read:
> > 
> > # Usage:
> > # split_into_halves   
> > 
> > function split_into_halves()
> > {
> > local value=$1
> > local upper=$2
> > local lower=$3
> > 
> > eval "$upper=$(printf "0x%X\n" $(($value >> 32)))"
> > eval "$lower=$(printf "0x%X\n" $(($value & 0x)))"
> > }
> That is ok for me.
> 
> > 
> > 
> >> +
> >>  # data_type is either
> >>  #   int
> >>  #   hex
> >> @@ -41,10 +49,14 @@ function dt_set()
> >>
> >>  if test $data_type = "var"
> >>  then
> >> -eval data_addr_var="$data"_addr
> >> -eval data_addr=\$"$data_addr_var"
> >> -eval data_size_var="$data"_size
> >> -eval data_size=\$"$data_size_var"
> >> +eval data_addr1_var="$data"_addr1
> >> +eval data_addr2_var="$data"_addr2
> >> +eval data_addr1=\$"$data_addr1_var"
> >> +eval data_addr2=\$"$data_addr2_var"
> >> +eval data_size1_var="$data"_size1
> >> +eval data_size2_var="$data"_size2
> >> +eval data_size1=\$"$data_size1_var"
> >> +eval data_size2=\$"$data_size2_var"
> > 
> > To avoid making the code more complex, is it possible to stick with just
> > a single data_addr variable in u-boot and calculate the upper and lower
> > 32-bit using u-boot commands?
> The reason why we need these extra variables is to add them into respective
> cells under different nodes. In dt_set we need to put the variable names
> for dynamic assignment and variable values for static assignment. We cannot
> do this having a single pair data_addr_var,data_addr. These evals corresponds
> to variables from xen_file_loading. dt_set and add_size are two different
> functions. The former is used to create the nodes and the latter is used to
> set values for the environment variables.
> 
> Example:
> dt_set "/chosen/dom0" "reg" "var" "dom0_linux"
> - this will create a reg property for dom0 kernel. We need to insert the upper
> and lower halves into this property (so we need separate variables for that)
> e.g.
> reg <0x${dom0_linux_addr1} 0x${dom0_linux_addr2} 0x${dom0_linux_size1} 
> 0x${dom0_linux_size2}>
> 
> load_file $DOM0_KERNEL "dom0_linux" calling add_size
> - this will set values for upper and lower halves into u-boot env variables
> that corresponds to variables we placed previously in reg property,
> e.g.
> setenv dom0_linux_addr1 ${memaddr1}
> setenv dom0_linux_addr2 ${memaddr2}
> setenv dom0_linux_size1 ${filesize1}
> setenv dom0_linux_size2 ${filesize2}
> 
> FWICS, we cannot achieve this using a single pair.

OK. In that case please rebase the patch on the "master-next" branch.
We'll figure out how to handle the dynamic address calculation at a
later time.

Re: [PATCH] xen/virtio: Handle PCI devices which Host controller is described in DT

2022-10-07 Thread Stefano Stabellini 
On Fri, 7 Oct 2022, Juergen Gross wrote:
> On 06.10.22 19:48, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko 
> > 
> > Use the same "xen-grant-dma" device concept (based on generic IOMMU
> > device-tree bindings) for the PCI devices behind device-tree based
> > PCI Host controller.
> > 
> > Signed-off-by: Oleksandr Tyshchenko 
> > ---
> > Slightly RFC. This is needed to support Xen grant mappings for virtio-pci
> > devices
> > on Arm at some point in the future. The Xen toolstack side is not published
> > yet.
> > Here, for PCI devices we use the same way to pass backend domid to the guest
> > as for
> > platform devices.
> 
> I should mention we decided at the Xen Summit, that I will start a try to
> modify the virtio spec to include the backend id (domid in the Xen case)
> in the device independent config part.

Good idea


> As this will take some time to be accepted (if ever), other means to
> specify the backend domid are needed until then. DT is one possibility
> (at least on Arm), while Xenstore is the way to go for setups with a
> Xen toolstack.

What do you think of my idea of using PCI config registers on the *root
complex* (not the device) to retrieve the information?

Re: Free Rtos porting on XEN

2022-10-07 Thread Stefano Stabellini 
Hi Dega,

For Xen on Raspberry PI 4, that should work out of the box now and there
are a few users on xen-devel that got it to work successfully recently.
One of the documents that describes how to get Xen to run on RPi4 in
details is the following, although it is 2 years old now:
https://xenproject.org/2020/09/29/xen-on-raspberry-pi-4-adventures/

Specifically for FreeRTOS, I cannot help as I don't have any experience
with FreeRTOS outside of Xilinx boards. However, it might help you
to begin with Xilinx FreeRTOS, which is known to work on Xen, then try
to see how to port it to RPi4. The link I provided
(https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842141/FreeRTOS)
should have detailed information about Xilinx FreeRTOS.

Cheers,

Stefano



On Fri, 7 Oct 2022, dega kiran wrote:
> Hi Stefano Stabellini ,
> Thanks for the reply.
> 
> We are currently working on Raspberry PI 4 can you help us how we can port 
> Xen with FreeRtos on Raspberry PI4.
> 
> Is there any reference I can go through for porting Xen with FreeRtos on 
> Raspberry PI4.?
> 
> 
> Thanks and regards,
> Dega. 
> 
> On Tue, Oct 4, 2022 at 9:48 AM dega kiran  wrote:
>   Hi ,
> I am trying to port FREERtos on XEN . But not getting any concrete 
> information for porting.
> 
> I am following https://github.com/GaloisInc/FreeRTOS-Xen
> 
> but getting a lot of errors.
> 
> Please Let me know how to follow the porting process.
> 
> 
> Thank you,
> Dega.
> 
> 
>

Re: [PATCH] xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts

2022-10-07 Thread Xenia Ragiadakou 



On 10/7/22 20:35, Oleksandr Tyshchenko wrote:

Hi Oleksandr


On 10/6/22 15:09, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Although XEN_PAGE_SIZE is equal to PAGE_SIZE (4KB) for now, it
would
be more correct to use Xen specific #define-s as XEN_PAGE_SIZE can
be changed at some point in the future.

Signed-off-by: Oleksandr Tyshchenko 
---
Cc: Juergen Gross 
Cc: Xenia Ragiadakou 

As it was proposed at:
https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20221005174823.1800761-1-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!zHt-xZ_7tZc_EM6zva21E_YgwIiEeimFWfsJIpPwAu-TBcnzQhXHqlKzmXmwIcI6uIx_arHNZiaZeHt_428_8p-DyMpd$


[lore[.]kernel[.]org]

Should go in only after that series.
---
     drivers/xen/grant-dma-ops.c | 20 ++--
     1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c
b/drivers/xen/grant-dma-ops.c
index c66f56d24013..5392fdc25dca 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -31,12 +31,12 @@ static
DEFINE_XARRAY_FLAGS(xen_grant_dma_devices,
XA_FLAGS_LOCK_IRQ);
       static inline dma_addr_t grant_to_dma(grant_ref_t grant)
     {
-    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
PAGE_SHIFT);
+    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
XEN_PAGE_SHIFT);
     }


With this change, can the offset added to the dma handle,
generated by
grant_to_dma(), be the offset in the page? Couldn't it corrupt the
grant ref?



Good point, indeed, I think it could corrupt if guest uses a
different
than Xen page granularity (i.e 64KB).





       static inline grant_ref_t dma_to_grant(dma_addr_t dma)
     {
-    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
PAGE_SHIFT);
+    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
XEN_PAGE_SHIFT);
     }
       static struct xen_grant_dma_data
*find_xen_grant_dma_data(struct
device *dev)
@@ -79,7 +79,7 @@ static void *xen_grant_dma_alloc(struct device
*dev, size_t size,
  unsigned long attrs)
     {
     struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(size);
+    unsigned int i, n_pages = XEN_PFN_UP(size);
     unsigned long pfn;
     grant_ref_t grant;
     void *ret;
@@ -91,14 +91,14 @@ static void *xen_grant_dma_alloc(struct device
*dev, size_t size,
     if (unlikely(data->broken))
     return NULL;
     -    ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
+    ret = alloc_pages_exact(n_pages * XEN_PAGE_SIZE, gfp);
     if (!ret)
     return NULL;
       pfn = virt_to_pfn(ret);
       if (gnttab_alloc_grant_reference_seq(n_pages, )) {
-    free_pages_exact(ret, n_pages * PAGE_SIZE);
+    free_pages_exact(ret, n_pages * XEN_PAGE_SIZE);
     return NULL;
     }
     @@ -116,7 +116,7 @@ static void xen_grant_dma_free(struct
device
*dev, size_t size, void *vaddr,
    dma_addr_t dma_handle, unsigned long attrs)
     {
     struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(size);
+    unsigned int i, n_pages = XEN_PFN_UP(size);
     grant_ref_t grant;
       data = find_xen_grant_dma_data(dev);
@@ -138,7 +138,7 @@ static void xen_grant_dma_free(struct device
*dev, size_t size, void *vaddr,
       gnttab_free_grant_reference_seq(grant, n_pages);
     -    free_pages_exact(vaddr, n_pages * PAGE_SIZE);
+    free_pages_exact(vaddr, n_pages * XEN_PAGE_SIZE);
     }
       static struct page *xen_grant_dma_alloc_pages(struct
device *dev,
size_t size,
@@ -168,7 +168,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
device *dev, struct page *page,
  unsigned long attrs)
     {
     struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(offset + size);
+    unsigned int i, n_pages = XEN_PFN_UP(offset + size);


The offset, here, refers to the offset in the page ...


     grant_ref_t grant;
     dma_addr_t dma_handle;
     @@ -200,8 +200,8 @@ static void xen_grant_dma_unmap_page(struct
device *dev, dma_addr_t dma_handle,
  unsigned long attrs)
     {
     struct xen_grant_dma_data *data;
-    unsigned long offset = dma_handle & (PAGE_SIZE - 1);
-    unsigned int i, n_pages = PFN_UP(offset + size);
+    unsigned long offset = dma_handle & ~XEN_PAGE_MASK;


... while, here, it refers to the offset in the grant.
So, the calculated number of grants may differ.


Good point, I think you are right, so we need to additionally use
xen_offset_in_page() macro in xen_grant_dma_map_page(),

something like that to be squashed with current patch:


diff --git a/drivers/xen/grant-dma-ops.c
b/drivers/xen/grant-dma-ops.c
index 9d5eca6d638a..bb984dc05deb 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -169,7 +169,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
device *dev, struct page *page,
     unsigned long attrs)
     {
      

Re: [PATCH] argo: Remove reachable ASSERT_UNREACHABLE

2022-10-07 Thread Andrew Cooper 
On 07/10/2022 20:31, Jason Andryuk wrote:
> I observed this ASSERT_UNREACHABLE in partner_rings_remove consistently
> trip.  It was in OpenXT with the viptables patch applied.
>
> dom10 shuts down.
> dom7 is REJECTED sending to dom10.
> dom7 shuts down and this ASSERT trips for dom10.
>
> The argo_send_info has a domid, but there is no refcount taken on
> the domain.  Therefore it's not appropriate to ASSERT that the domain
> can be looked up via domid.  Replace with a debug message.
>
> Signed-off-by: Jason Andryuk 

We're into the 4.17 release process now.  A bugfix like this obviously
should be considered, but will need approval from the release manager. 
CC Henry.

~Andrew

> ---
>  xen/common/argo.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/argo.c b/xen/common/argo.c
> index 748b8714d6..973e1e9956 100644
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -1298,7 +1298,8 @@ partner_rings_remove(struct domain *src_d)
>  ASSERT_UNREACHABLE();
>  }
>  else
> -ASSERT_UNREACHABLE();
> +argo_dprintk("%pd has entry for stale partner domid %d\n",
> + src_d, send_info->id.domain_id);
>  
>  if ( dst_d )
>  rcu_unlock_domain(dst_d);

Re: [PATCH 9/9] gnttab: don't silently truncate GFNs in compat setup-table handling

2022-10-07 Thread Andrew Cooper 
On 26/08/2021 11:15, Jan Beulich wrote:
> Returning back truncated frame numbers is unhelpful: Quite likely
> they're not owned by the domain (if it's PV), or we may misguide the
> guest into writing grant entries into a page that it actually uses for
> other purposes.
> Signed-off-by: Jan Beulich 
> ---
> RFC: Arguably in the 32-bit PV case it may be necessary to instead put
>  in place an explicit address restriction when allocating
>  ->shared_raw[N]. This is currently implicit by alloc_xenheap_page()
>  only returning memory covered by the direct-map.

Yet another reason why having the grant table be Xen memory, rather than
guest memory, was a terrible idea.  Changing this is in consideration
for the encrypted vm work.

Its fine for now, but is fragile and liable to break for e.g. an
xmalloc() -> vmalloc() conversion, or when we get 5-level paging and the
directmap boundary moves above 16T.



> --- a/xen/common/compat/grant_table.c
> +++ b/xen/common/compat/grant_table.c
> @@ -175,8 +175,15 @@ int compat_grant_table_op(unsigned int c
>   i < (_s_)->nr_frames; ++i ) \
>  { \
>  compat_pfn_t frame = (_s_)->frame_list.p[i]; \
> -if ( __copy_to_compat_offset((_d_)->frame_list, \
> - i, , 1) ) \
> +if ( frame != (_s_)->frame_list.p[i] ) \
> +{ \
> +if ( VALID_M2P((_s_)->frame_list.p[i]) ) \
> +(_s_)->status = GNTST_address_too_big; \
> +else \
> +frame |= 0x8000U;\

Space before the \.  (This is one reason why I hate this style.  The
borderline illegibility makes it almost impossible to spot style problems.)

With the adjustment from the previous patch, you'll need a break in here.

But for !valid case, shouldn't we saturate to ~0u ?  I recall from the
migration work that various kernels disagree on what constitutes an
invalid MFN.

Then again, I can't see what legitimate case we'd have for a truncation
and an invalid M2P entry needing translating.

~Andrew

> +} \
> +else if ( __copy_to_compat_offset((_d_)->frame_list, 
> \
> +  i, , 1) ) \
>  (_s_)->status = GNTST_bad_virt_addr; \
>  } \
>  } while (0)
>
>

Re: [PATCH 8/9] gnttab: bail from GFN-storing loops early in case of error

2022-10-07 Thread Andrew Cooper 
On 26/08/2021 11:14, Jan Beulich wrote:
> The contents of the output arrays are undefined in both cases anyway
> when the operation itself gets marked as failed. There's no value in
> trying to continue after a guest memory access failure.
>
> Signed-off-by: Jan Beulich 

Not really Acked-by: Andrew Cooper 

This is an example of a bad loop adjustment.  Taking just one example to
demonstrate with,

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3289,17 +3292,15 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
>   "status frames, but has only %u\n",
>   d->domain_id, op.nr_frames, nr_status_frames(gt));
>  op.status = GNTST_general_error;
> -goto unlock;
>  }
>  
> -for ( i = 0; i < op.nr_frames; i++ )
> +for ( i = 0; op.status == GNTST_okay && i < op.nr_frames; i++ )
>  {
>  gmfn = gfn_x(gnttab_status_gfn(d, gt, i));
>  if ( __copy_to_guest_offset(op.frame_list, i, , 1) )
>  op.status = GNTST_bad_virt_addr;
>  }
>  
> - unlock:
>  grant_read_unlock(gt);
>   out2:
>  rcu_unlock_domain(d);
>


If instead, this were written

    for ( i = 0; i < op.nr_frames; i++ )
    {
    gmfn = gfn_x(gnttab_status_gfn(d, gt, i));
    if ( __copy_to_guest_offset(op.frame_list, i, , 1) )
    {
    op.status = GNTST_bad_virt_addr;
    goto unlock;
    }
    }

then the delta vs your version is -36 bytes, and faster to run because
the loop doesn't need a memory read and compare on every iteration when
you can exit based purely on existing control flow.

Furthermore, the version with a goto is clearer to follow, because the
exit condition is much more obvious.  The compat change can do the same
with breaks rather than gotos, for a slightly more modest -11 saving.

A form with the op.status changes adjustments *not* added to the loop
condition, Reviewed-by: Andrew Cooper 


In reference to the hypercall ABI adjustments, it occurs to me that
loops like this (which we have loads of, even in hypercall hotpaths) are
horrifying for performance.  For HVM, we're redoing the nested pagewalk
for every uint64_t element of an array. 

A "copy array to guest" primitive would more efficient still than a
plain virt->phys translation, because we'd be able to drop the p2m walks
too.

Obviously, we don't want every instance like this to be doing its own
manual bounce buffering, so perhaps we should invest in some buffered
copy helpers as part of trying to improve hypercall performance.

~Andrew

[PATCH] argo: Remove reachable ASSERT_UNREACHABLE

2022-10-07 Thread Jason Andryuk 
I observed this ASSERT_UNREACHABLE in partner_rings_remove consistently
trip.  It was in OpenXT with the viptables patch applied.

dom10 shuts down.
dom7 is REJECTED sending to dom10.
dom7 shuts down and this ASSERT trips for dom10.

The argo_send_info has a domid, but there is no refcount taken on
the domain.  Therefore it's not appropriate to ASSERT that the domain
can be looked up via domid.  Replace with a debug message.

Signed-off-by: Jason Andryuk 
---
 xen/common/argo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/common/argo.c b/xen/common/argo.c
index 748b8714d6..973e1e9956 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -1298,7 +1298,8 @@ partner_rings_remove(struct domain *src_d)
 ASSERT_UNREACHABLE();
 }
 else
-ASSERT_UNREACHABLE();
+argo_dprintk("%pd has entry for stale partner domid %d\n",
+ src_d, send_info->id.domain_id);
 
 if ( dst_d )
 rcu_unlock_domain(dst_d);
-- 
2.37.3

[linux-linus test] 173456: tolerable FAIL - PUSHED

2022-10-07 Thread osstest service owner 
flight 173456 linux-linus real [real]
flight 173460 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173456/
http://logs.test-lab.xenproject.org/osstest/logs/173460/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  10 host-ping-check-xen fail pass in 173460-retest

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

version targeted for testing:
 linux4c86114194e644b6da9107d75910635c9e87179e
baseline version:
 linuxffb39098bf87db327b2be4b5c6f1087bcba94ce9

Last test of basis   173451  2022-10-06 21:13:17 Z0 days
Testing same since   173456  2022-10-07 08:23:54 Z0 days1 attempts


People who touched revisions under test:
  Al Viro 
  Alexander Zhu 
  Alexey Lyashkov 
  Amir Goldstein 
  Andrew Perepechko 
  Baokun Li 
  BingJing Chang 
  Boris Burkov 
  Casey

Re: [PATCH 7/9] gnttab: no need to translate handle for gnttab_get_status_frames()

2022-10-07 Thread Andrew Cooper 
On 26/08/2021 11:14, Jan Beulich wrote:
> Unlike for GNTTABOP_setup_table native and compat frame lists are arrays

"GNTTABOP_setup_table, native"

But I think it would also be clearer to follow with

"frame lists for GNTTABOP_get_status_frames are of".

> of the same type (uint64_t). Hence there's no need to translate the frame
> values. This then also renders unnecessary the limit_max parameter of
> gnttab_get_status_frames().
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper

Re: [PATCH 0/9] gnttab: further work from XSA-380 / -382 context

2022-10-07 Thread Andrew Cooper 
On 07/10/2022 14:49, Jan Beulich wrote:
> On 26.08.2021 12:06, Jan Beulich wrote:
>> The first four patches can be attributed to the former, the last four
>> patches to the latter. The middle patch had been submitted standalone
>> before, has a suitable Reviewed-by tag, but also has an objection by
>> Andrew pending, which unfortunately has lead to this patch now being
>> stuck. Short of Andrew being willing to settle the disagreement more
>> with Julien than with me (although I'm on Julien's side), I have no
>> idea what to do here.
>>
>> There's probably not much interrelation between the patches, so they
>> can perhaps go in about any order.
>>
>> 1: defer allocation of maptrack frames table
>> 2: drop a redundant expression from gnttab_release_mappings()
>> 3: fold recurring is_iomem_page()
>> 4: drop GNTMAP_can_fail
>> 5: defer allocation of status frame tracking array
> Just to make "official" what I've said in the course of the resource
> management discussion at the event in Cambridge: I'm withdrawing 1
> and 5, in the expectation that eager/lazy allocation of resources
> will become a property to be honored uniformly for a guest. With 2,
> 3, 4, and 6 already having gone in, it would still be nice to
> (finally) have feedback on ...

To these issues in particular, there was specific work done in 4.16 to
address the impasse in a way which got the savings in most cases, but
without increasing the risk of hitting known buggy paths in guest drivers.


For patch 5, the ABI max version is now known to domain_create(), so the
status array allocation can safely be skipped when gnttab v2 isn't
available.

This gets the saving Julien wants on ARM, and on x86 we ought to
encourage people to restricting to v1 where possible, so they get the
savings too.


For patch 1, I agree with the observation that 1024 maptrack frames is a
silly default to have.  Adjusting this appropriately will result in the
kind of savings wanted in the patch, without modifying the hypervisor
directly.

We should have a patch to xl (or is it libxl?) to make a better choice
than blindly picking 1024.

Having written this out, something does strike me as odd.  These limits
are specified in frames, and for the gnttab limit, this equates into a
known number of grants.  But struct maptrack is internal Xen, so the
toolstack selecting 1024 frames can't know how many grant maps that
actually equates to in Xen.  Right now, 1024 maptrack frames equates to
2^18 mappings (I think).


For traditional server-virt VMs, they can have 0 because the frontends
should never be mapping grants.  We actually already do this for the
xenstored stubdom.  The same is almost certainly true for qemu stubdoms.

For VMs in a bit of a more interesting configuration, e.g. with virtio,
then they need "some".

For device driver VMs, they do need a dom0-like mapping capabilities.

Either way, there is definitely room to improve the status quo without
impacting runtime safety.  If patches were to appear promptly, I think
there's probably wiggle room to consider them for 4.17 at this point.

~Andrew

Re: [PATCH] xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts

2022-10-07 Thread Oleksandr Tyshchenko 

On 07.10.22 19:16, Oleksandr wrote:

Hello Xenia

>
> On 07.10.22 18:50, Xenia Ragiadakou wrote:
>
>
> Hello Xenia
>
>>
>> On 10/7/22 16:43, Oleksandr Tyshchenko wrote:
>>>
>>> On 07.10.22 10:15, Xenia Ragiadakou wrote:

 On 10/7/22 00:13, Oleksandr Tyshchenko wrote:

 Hi Oleksandr
>>>
>>>
>>> Hello Xenia
>>>
>>>

>
> On 06.10.22 20:59, Xenia Ragiadakou wrote:
>
> Hello Xenia
>
>>
>> On 10/6/22 15:09, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko 
>>>
>>> Although XEN_PAGE_SIZE is equal to PAGE_SIZE (4KB) for now, it 
>>> would
>>> be more correct to use Xen specific #define-s as XEN_PAGE_SIZE can
>>> be changed at some point in the future.
>>>
>>> Signed-off-by: Oleksandr Tyshchenko 
>>> ---
>>> Cc: Juergen Gross 
>>> Cc: Xenia Ragiadakou 
>>>
>>> As it was proposed at:
>>> https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20221005174823.1800761-1-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!zHt-xZ_7tZc_EM6zva21E_YgwIiEeimFWfsJIpPwAu-TBcnzQhXHqlKzmXmwIcI6uIx_arHNZiaZeHt_428_8p-DyMpd$
>>>  
>>>
>>>
>>> [lore[.]kernel[.]org]
>>>
>>> Should go in only after that series.
>>> ---
>>>     drivers/xen/grant-dma-ops.c | 20 ++--
>>>     1 file changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/xen/grant-dma-ops.c 
>>> b/drivers/xen/grant-dma-ops.c
>>> index c66f56d24013..5392fdc25dca 100644
>>> --- a/drivers/xen/grant-dma-ops.c
>>> +++ b/drivers/xen/grant-dma-ops.c
>>> @@ -31,12 +31,12 @@ static 
>>> DEFINE_XARRAY_FLAGS(xen_grant_dma_devices,
>>> XA_FLAGS_LOCK_IRQ);
>>>       static inline dma_addr_t grant_to_dma(grant_ref_t grant)
>>>     {
>>> -    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
>>> PAGE_SHIFT);
>>> +    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
>>> XEN_PAGE_SHIFT);
>>>     }
>>
>> With this change, can the offset added to the dma handle, 
>> generated by
>> grant_to_dma(), be the offset in the page? Couldn't it corrupt the
>> grant ref?
>
>
> Good point, indeed, I think it could corrupt if guest uses a 
> different
> than Xen page granularity (i.e 64KB).
>
>
>>
>>>       static inline grant_ref_t dma_to_grant(dma_addr_t dma)
>>>     {
>>> -    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
>>> PAGE_SHIFT);
>>> +    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
>>> XEN_PAGE_SHIFT);
>>>     }
>>>       static struct xen_grant_dma_data 
>>> *find_xen_grant_dma_data(struct
>>> device *dev)
>>> @@ -79,7 +79,7 @@ static void *xen_grant_dma_alloc(struct device
>>> *dev, size_t size,
>>>  unsigned long attrs)
>>>     {
>>>     struct xen_grant_dma_data *data;
>>> -    unsigned int i, n_pages = PFN_UP(size);
>>> +    unsigned int i, n_pages = XEN_PFN_UP(size);
>>>     unsigned long pfn;
>>>     grant_ref_t grant;
>>>     void *ret;
>>> @@ -91,14 +91,14 @@ static void *xen_grant_dma_alloc(struct device
>>> *dev, size_t size,
>>>     if (unlikely(data->broken))
>>>     return NULL;
>>>     -    ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
>>> +    ret = alloc_pages_exact(n_pages * XEN_PAGE_SIZE, gfp);
>>>     if (!ret)
>>>     return NULL;
>>>       pfn = virt_to_pfn(ret);
>>>       if (gnttab_alloc_grant_reference_seq(n_pages, )) {
>>> -    free_pages_exact(ret, n_pages * PAGE_SIZE);
>>> +    free_pages_exact(ret, n_pages * XEN_PAGE_SIZE);
>>>     return NULL;
>>>     }
>>>     @@ -116,7 +116,7 @@ static void xen_grant_dma_free(struct 
>>> device
>>> *dev, size_t size, void *vaddr,
>>>    dma_addr_t dma_handle, unsigned long attrs)
>>>     {
>>>     struct xen_grant_dma_data *data;
>>> -    unsigned int i, n_pages = PFN_UP(size);
>>> +    unsigned int i, n_pages = XEN_PFN_UP(size);
>>>     grant_ref_t grant;
>>>       data = find_xen_grant_dma_data(dev);
>>> @@ -138,7 +138,7 @@ static void xen_grant_dma_free(struct device
>>> *dev, size_t size, void *vaddr,
>>>       gnttab_free_grant_reference_seq(grant, n_pages);
>>>     -    free_pages_exact(vaddr, n_pages * PAGE_SIZE);
>>> +    free_pages_exact(vaddr, n_pages * XEN_PAGE_SIZE);
>>>     }
>>>       static struct page *xen_grant_dma_alloc_pages(struct 
>>> device *dev,
>>> size_t size,
>>> @@ -168,7 +168,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
>>> device *dev, struct page *page,
>>>  unsigned long attrs)
>>>     {
>>>     struct xen_grant_dma_data *data;
>>> -    unsigned int i, n_pages = PFN_UP(offset +

Re: [PATCH v2 0/2] xen/gntdev: Fixes for leaks and VMA splitting

2022-10-07 Thread Demi Marie Obenour 
On Fri, Oct 07, 2022 at 07:17:41AM +0200, Juergen Gross wrote:
> On 03.10.22 00:20, M. Vefa Bicakci wrote:
> > Hi all,
> > 
> > First of all, sorry for the delay!
> > 
> > These patches continue the code review for the following patches:
> >
> > https://lore.kernel.org/xen-devel/20220912040002.198191-1-m@runbox.com/t/#u
> > 
> > The original description of the patch set is as follows:
> > 
> >"The changes in this patch series intend to fix the Xen grant device
> >driver, so that grant mapping leaks caused by partially failed grant
> >mapping operations are avoided with the first patch, and so that the
> >splitting of VMAs does not result in incorrectly unmapped grant pages
> >with the second patch. The second patch also prevents a similar issue
> >in a double-mapping scenario, where mmap() is used with MAP_FIXED to
> >map grants over an existing mapping created with the same grants, and
> >where grant pages are unmapped incorrectly as well."
> > 
> > A summary of the changes from v1 is as follows:
> > - Addressed Juergen's code review comment regarding the first patch.
> > - Amended the description of the second patch to note that the described
> >issues are encountered with PV domains.
> > 
> > Verification notes:
> > 
> > - I have tested these commits on top of Linux v5.15.70 and v5.15.71, and
> >I verified that they compile successfully on top of the tag
> >"next-20220930", which corresponds to the base commit ID included at
> >the bottom of this e-mail.
> > 
> > - My tests consist of using a kernel with Qubes OS v4.1's patches and
> >these patches on my main computer for day-to-day tasks, in conjunction
> >with Qubes OS's version of the Xen hypervisor v4.14.5, with the latter
> >custom-compiled with CONFIG_DEBUG.
> > 
> > - I used a test program that verifies the following scenarios with an
> >unprivileged paravirtualized (PV) Xen domain:
> > 
> >- A program mmap()s two pages from another Xen domain and munmap()s
> >  the pages one by one. This used to result in implicit unmap errors
> >  to be reported by Xen and a general protection fault to be triggered
> >  by Xen in the affected domain, but now works as expected.
> >- A program mmap()s two pages from another Xen domain and then
> >  attempts to remap (via MAP_FIXED) the same mapping again over the
> >  same virtual address. This used to result in similar issues
> >  (implicit unmap errors and general protection fault), but now is
> >  rejected by the kernel.
> >- A program mmap()s two pages from another Xen domain and then
> >  attempts to mmap() the same mapping again to a different virtual
> >  address, by passing NULL as mmap()'s first argument. This used to be
> >  rejected by the kernel, and it continues to be rejected by the
> >  kernel.
> > 
> > - Unprivileged PVH Xen domains were also sanity tested with the same
> >test program. I should note that PVH domains worked as expected
> >without these patches too.
> > 
> > - Finally, I have verified that the original "g.e. 0x1234 still pending"
> >issue does not appear after rapidly resizing GUI windows in Qubes OS
> >v4.1.
> 
> Series pushed to xen/tip.git for-linus-6.1

Thanks!
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab


signature.asc
Description: PGP signature

[linux-5.4 test] 173454: tolerable FAIL - PUSHED

2022-10-07 Thread osstest service owner 
flight 173454 linux-5.4 real [real]
flight 173458 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173454/
http://logs.test-lab.xenproject.org/osstest/logs/173458/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail pass in 
173458-retest

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

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

2022-10-07 Thread osstest service owner 
flight 173457 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173457/

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  9029bc265cdf2bd63376dde9fdd91db4ce9c0586
baseline version:
 xen  66a5633aa038f4abb4455463755974febac69034

Last test of basis   173428  2022-10-05 09:00:30 Z2 days
Testing same since   173457  2022-10-07 14:03:14 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

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
   66a5633aa0..9029bc265c  9029bc265cdf2bd63376dde9fdd91db4ce9c0586 -> smoke

Re: [PATCH] xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts

2022-10-07 Thread Oleksandr Tyshchenko 

On 07.10.22 18:50, Xenia Ragiadakou wrote:


Hello Xenia

>
> On 10/7/22 16:43, Oleksandr Tyshchenko wrote:
>>
>> On 07.10.22 10:15, Xenia Ragiadakou wrote:
>>>
>>> On 10/7/22 00:13, Oleksandr Tyshchenko wrote:
>>>
>>> Hi Oleksandr
>>
>>
>> Hello Xenia
>>
>>
>>>

 On 06.10.22 20:59, Xenia Ragiadakou wrote:

 Hello Xenia

>
> On 10/6/22 15:09, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko 
>>
>> Although XEN_PAGE_SIZE is equal to PAGE_SIZE (4KB) for now, it would
>> be more correct to use Xen specific #define-s as XEN_PAGE_SIZE can
>> be changed at some point in the future.
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> ---
>> Cc: Juergen Gross 
>> Cc: Xenia Ragiadakou 
>>
>> As it was proposed at:
>> https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20221005174823.1800761-1-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!zHt-xZ_7tZc_EM6zva21E_YgwIiEeimFWfsJIpPwAu-TBcnzQhXHqlKzmXmwIcI6uIx_arHNZiaZeHt_428_8p-DyMpd$
>>  
>>
>>
>> [lore[.]kernel[.]org]
>>
>> Should go in only after that series.
>> ---
>>     drivers/xen/grant-dma-ops.c | 20 ++--
>>     1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/xen/grant-dma-ops.c 
>> b/drivers/xen/grant-dma-ops.c
>> index c66f56d24013..5392fdc25dca 100644
>> --- a/drivers/xen/grant-dma-ops.c
>> +++ b/drivers/xen/grant-dma-ops.c
>> @@ -31,12 +31,12 @@ static 
>> DEFINE_XARRAY_FLAGS(xen_grant_dma_devices,
>> XA_FLAGS_LOCK_IRQ);
>>       static inline dma_addr_t grant_to_dma(grant_ref_t grant)
>>     {
>> -    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
>> PAGE_SHIFT);
>> +    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
>> XEN_PAGE_SHIFT);
>>     }
>
> With this change, can the offset added to the dma handle, 
> generated by
> grant_to_dma(), be the offset in the page? Couldn't it corrupt the
> grant ref?


 Good point, indeed, I think it could corrupt if guest uses a different
 than Xen page granularity (i.e 64KB).


>
>>       static inline grant_ref_t dma_to_grant(dma_addr_t dma)
>>     {
>> -    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
>> PAGE_SHIFT);
>> +    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
>> XEN_PAGE_SHIFT);
>>     }
>>       static struct xen_grant_dma_data 
>> *find_xen_grant_dma_data(struct
>> device *dev)
>> @@ -79,7 +79,7 @@ static void *xen_grant_dma_alloc(struct device
>> *dev, size_t size,
>>  unsigned long attrs)
>>     {
>>     struct xen_grant_dma_data *data;
>> -    unsigned int i, n_pages = PFN_UP(size);
>> +    unsigned int i, n_pages = XEN_PFN_UP(size);
>>     unsigned long pfn;
>>     grant_ref_t grant;
>>     void *ret;
>> @@ -91,14 +91,14 @@ static void *xen_grant_dma_alloc(struct device
>> *dev, size_t size,
>>     if (unlikely(data->broken))
>>     return NULL;
>>     -    ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
>> +    ret = alloc_pages_exact(n_pages * XEN_PAGE_SIZE, gfp);
>>     if (!ret)
>>     return NULL;
>>       pfn = virt_to_pfn(ret);
>>       if (gnttab_alloc_grant_reference_seq(n_pages, )) {
>> -    free_pages_exact(ret, n_pages * PAGE_SIZE);
>> +    free_pages_exact(ret, n_pages * XEN_PAGE_SIZE);
>>     return NULL;
>>     }
>>     @@ -116,7 +116,7 @@ static void xen_grant_dma_free(struct device
>> *dev, size_t size, void *vaddr,
>>    dma_addr_t dma_handle, unsigned long attrs)
>>     {
>>     struct xen_grant_dma_data *data;
>> -    unsigned int i, n_pages = PFN_UP(size);
>> +    unsigned int i, n_pages = XEN_PFN_UP(size);
>>     grant_ref_t grant;
>>       data = find_xen_grant_dma_data(dev);
>> @@ -138,7 +138,7 @@ static void xen_grant_dma_free(struct device
>> *dev, size_t size, void *vaddr,
>>       gnttab_free_grant_reference_seq(grant, n_pages);
>>     -    free_pages_exact(vaddr, n_pages * PAGE_SIZE);
>> +    free_pages_exact(vaddr, n_pages * XEN_PAGE_SIZE);
>>     }
>>       static struct page *xen_grant_dma_alloc_pages(struct device 
>> *dev,
>> size_t size,
>> @@ -168,7 +168,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
>> device *dev, struct page *page,
>>  unsigned long attrs)
>>     {
>>     struct xen_grant_dma_data *data;
>> -    unsigned int i, n_pages = PFN_UP(offset + size);
>> +    unsigned int i, n_pages = XEN_PFN_UP(offset + size);
>
> The offset, here, refers to the offset in the page ...
>
>>     grant_ref_t grant;
>>     dma_addr_t dma_handle;

Re: [PATCH v2 3/3] xen/virtio: enable grant based virtio on x86

2022-10-07 Thread Boris Ostrovsky 



On 10/7/22 10:00 AM, Oleksandr Tyshchenko wrote:

On 07.10.22 09:41, Juergen Gross wrote:

Hello Juergen


Use an x86-specific virtio_check_mem_acc_cb() for Xen in order to setup
the correct DMA ops.

Signed-off-by: Juergen Gross 
---
V2:
- add missing PV check in xen_virtio_mem_acc() (Oleksandr Tyshchenko)
- add xen_virtio_restricted_mem_acc() stub (Oleksandr Tyshchenko)


Reviewed-by: Oleksandr Tyshchenko  #
common code




Reviewed-by: Boris Ostrovsky

Re: [PATCH] xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts

2022-10-07 Thread Xenia Ragiadakou 



On 10/7/22 16:43, Oleksandr Tyshchenko wrote:


On 07.10.22 10:15, Xenia Ragiadakou wrote:


On 10/7/22 00:13, Oleksandr Tyshchenko wrote:

Hi Oleksandr



Hello Xenia






On 06.10.22 20:59, Xenia Ragiadakou wrote:

Hello Xenia



On 10/6/22 15:09, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Although XEN_PAGE_SIZE is equal to PAGE_SIZE (4KB) for now, it would
be more correct to use Xen specific #define-s as XEN_PAGE_SIZE can
be changed at some point in the future.

Signed-off-by: Oleksandr Tyshchenko 
---
Cc: Juergen Gross 
Cc: Xenia Ragiadakou 

As it was proposed at:
https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20221005174823.1800761-1-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!zHt-xZ_7tZc_EM6zva21E_YgwIiEeimFWfsJIpPwAu-TBcnzQhXHqlKzmXmwIcI6uIx_arHNZiaZeHt_428_8p-DyMpd$

[lore[.]kernel[.]org]

Should go in only after that series.
---
    drivers/xen/grant-dma-ops.c | 20 ++--
    1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index c66f56d24013..5392fdc25dca 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -31,12 +31,12 @@ static DEFINE_XARRAY_FLAGS(xen_grant_dma_devices,
XA_FLAGS_LOCK_IRQ);
      static inline dma_addr_t grant_to_dma(grant_ref_t grant)
    {
-    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
PAGE_SHIFT);
+    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
XEN_PAGE_SHIFT);
    }


With this change, can the offset added to the dma handle, generated by
grant_to_dma(), be the offset in the page? Couldn't it corrupt the
grant ref?



Good point, indeed, I think it could corrupt if guest uses a different
than Xen page granularity (i.e 64KB).





      static inline grant_ref_t dma_to_grant(dma_addr_t dma)
    {
-    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
PAGE_SHIFT);
+    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
XEN_PAGE_SHIFT);
    }
      static struct xen_grant_dma_data *find_xen_grant_dma_data(struct
device *dev)
@@ -79,7 +79,7 @@ static void *xen_grant_dma_alloc(struct device
*dev, size_t size,
     unsigned long attrs)
    {
    struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(size);
+    unsigned int i, n_pages = XEN_PFN_UP(size);
    unsigned long pfn;
    grant_ref_t grant;
    void *ret;
@@ -91,14 +91,14 @@ static void *xen_grant_dma_alloc(struct device
*dev, size_t size,
    if (unlikely(data->broken))
    return NULL;
    -    ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
+    ret = alloc_pages_exact(n_pages * XEN_PAGE_SIZE, gfp);
    if (!ret)
    return NULL;
      pfn = virt_to_pfn(ret);
      if (gnttab_alloc_grant_reference_seq(n_pages, )) {
-    free_pages_exact(ret, n_pages * PAGE_SIZE);
+    free_pages_exact(ret, n_pages * XEN_PAGE_SIZE);
    return NULL;
    }
    @@ -116,7 +116,7 @@ static void xen_grant_dma_free(struct device
*dev, size_t size, void *vaddr,
   dma_addr_t dma_handle, unsigned long attrs)
    {
    struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(size);
+    unsigned int i, n_pages = XEN_PFN_UP(size);
    grant_ref_t grant;
      data = find_xen_grant_dma_data(dev);
@@ -138,7 +138,7 @@ static void xen_grant_dma_free(struct device
*dev, size_t size, void *vaddr,
      gnttab_free_grant_reference_seq(grant, n_pages);
    -    free_pages_exact(vaddr, n_pages * PAGE_SIZE);
+    free_pages_exact(vaddr, n_pages * XEN_PAGE_SIZE);
    }
      static struct page *xen_grant_dma_alloc_pages(struct device *dev,
size_t size,
@@ -168,7 +168,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
device *dev, struct page *page,
     unsigned long attrs)
    {
    struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(offset + size);
+    unsigned int i, n_pages = XEN_PFN_UP(offset + size);


The offset, here, refers to the offset in the page ...


    grant_ref_t grant;
    dma_addr_t dma_handle;
    @@ -200,8 +200,8 @@ static void xen_grant_dma_unmap_page(struct
device *dev, dma_addr_t dma_handle,
     unsigned long attrs)
    {
    struct xen_grant_dma_data *data;
-    unsigned long offset = dma_handle & (PAGE_SIZE - 1);
-    unsigned int i, n_pages = PFN_UP(offset + size);
+    unsigned long offset = dma_handle & ~XEN_PAGE_MASK;


... while, here, it refers to the offset in the grant.
So, the calculated number of grants may differ.


Good point, I think you are right, so we need to additionally use
xen_offset_in_page() macro in xen_grant_dma_map_page(),

something like that to be squashed with current patch:


diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 9d5eca6d638a..bb984dc05deb 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -169,7 +169,7 @@ static dma_addr_t

Re: [PATCH] xen/virtio: Handle cases when page offset > PAGE_SIZE properly

2022-10-07 Thread Juergen Gross 

On 07.10.22 15:27, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Passed to xen_grant_dma_map_page() offset in the page
can be > PAGE_SIZE even if the guest uses the same page granularity
as Xen (4KB).

Before current patch, if such case happened we ended up providing
grants for the whole region in xen_grant_dma_map_page() which
was really unnecessary. The more, we ended up not releasing all
grants which represented that region in xen_grant_dma_unmap_page().

Current patch updates the code to be able to deal with such cases.

Signed-off-by: Oleksandr Tyshchenko 


Reviewed-by: Juergen Gross 


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Support for UEFI guest booting on Xen x86 (Was: Re: xen ovmf/uefi firmware does not save screen resolution)

2022-10-07 Thread Chuck Zmudzinski 
On 10/7/2022 8:02 AM, Chuck Zmudzinski wrote:
> On 10/6/2022 9:38 AM, Liberalia Tempus, S.L. wrote:
> > Thank you very much for your answers.
> >
> > Finally, after trying some of the solutions proposed by Chuck, I have 
> > made the decision to delete the UEFI partition and move it to a normal 
> > MBR system.
>
> Did you know you can keep the GPT partitions and the EFI partition and boot 
> HVM guests
> using MBR (seabios) with a GPT BIOS Boot partition present in the guest's 
> virtual boot disk?
> I implemented that by stealing the last 1 MB of the EFI GPT partition and 
> assigned that 1 MB
> to be a BIOS boot GPT partition, and grub2 is smart enough to install its own 
> MBR bootcode
> into that partition and it works fine in Xen HVMs by using seabios instead of 
> ovmf as the
> firmware/bios for the guest in the xl.cfg guest configuration file. But 
> that's not necessary if
> you are going to give up on using the EFI partition and GPT partitions and go 
> back to the
> legacy MBR partitioning scheme. What you are doing is a sensible option also 
> given Xen's
> current lack of support for UEFI booting of Xen HVM guests that actually 
> works.
>
> > I think it's too cumbersome all this xen and UEFI booting stuff and 
> > there's no point in spending more time on it. At the end of the day what 
> > matters in a virtual environment is that the machine works, regardless 
> > of the system used to boot.
> > As of today, UEFI booting does not work properly in xen/qemu, at least 
> > not for people who are not experts in xen code.
> > Best regards.
> >
> > PS: Chuck, what you say about version 4.14 I have not been able to apply 
> > in a vm with windows 10. It seems to work with a hvm vm with linux, but 
> > not with a windows vm.
>
> That may be true, because I have only tried UEFI booting of a Linux HVM 
> guest. I have always
> used MBR booting of Windows HVM guests with either the stdvga Qemu emulated 
> graphics
> device as the Windows HVM guest's primary graphics device or VGA passthrough 
> of the Intel
> IGD graphics device to the HVM Windows guest as the guest's primary graphics 
> device.
>
> I will in the meantime try to get UEFI booting working for both Windows and 
> Linux HVM guests
> for the future and at the same time use the BIOS boot GPT partition hack to 
> give me the option to
> use MBR booting with seabios instead of ovmf as the firmware/bios for the HVM 
> guest until
> Xen works well enough with UEFI booting of HVM guests. Obviously the MBR 
> technology is legacy
> tech and Xen needs to eventually be updated to support the UEFI booting 
> method of HVM guests
> going forward. I am not aware of much work in this area being done by the Xen 
> developers, but
> I am not subscribed to xen-devel so I could be wrong about that and I would 
> welcome any
> Xen developer who could explain to Xen users what work is being done to 
> support UEFI booting
> of Xen HVM guests in the future.

Specifically, what is Xen's current strategy for supporting UEFI booting of 
guests (Windows, Linux, etc.)
on the x86 Xen hypervisor?

For example, is using HVM guests with the upstream Qemu device model considered 
legacy tech and
the work to develop support for UEFI booting in the future should be done using 
PVH guests instead
of HVM guests?

Kind regards,

Chuck

>
> Best regards,
>
> Chuck
>
> >
> > -
> > MhBeyle __
> > > Date: Thu, 22 Sep 2022 11:25:41 -0400
> > > From: Chuck Zmudzinski 
> > >
> > >
> > > On 9/22/2022 4:37 AM, mhbe...@yahoo.es wrote:
> > >> Thanks for the answers.
> > >>
> > >> Chuck, I tried at the time to apply suggested patches to the software
> > >> with no results. It is not clear that any of the current patches solve
> > >> the problem.
> > >>
> > >> I think there are two problems here: One, the virtual machine that
> > >> creates xen uses QEMU and the UEFI bios is not able to communicate the
> > >> resolution data to the system. Two, this kind of problem would be easily
> > >> solved by virtualizing a more modern vga instead of the current cards
> > >> (cirrus etc.)
> > > Actually, this might be a bug in Xen 4.16 that was not in Xen 4.14.
> > >
> > > On Debian 11 (bullseye/stable for Dom0) booting HVM with Tiano Core
> > > UEFI works for me using vga = stdvga and videoram = 16:
> > >
> > > With Debian 11.x stable for dom0, the Xen version is 4.14 and the Qemu
> > > version is a bit old, 5.2, but booting with ovmf/uefi works:
> > >
> > > I boot Debian 11.x (stable) in a Xen HVM using ovmf using vga = stdvga in 
> > > the
> > > xl.cfg and it seems to work in a VNC window. I can get 1920x1080 
> > > resolution
> > > (with videoram = 16 in the xl.cfg), but this only works on Debian stable 
> > > dom0
> > > with Xen version 4.14.x and Qemu version 5.1 (haven't checked if Debian
> > > backported Qemu version 7.0 for Debian 11 also works).
> > >
> > > After login, use the gnome display settings and it gives the option of up
> > > to 1920x1080 resolution with

Re: [PATCH v2 3/3] xen/virtio: enable grant based virtio on x86

2022-10-07 Thread Oleksandr Tyshchenko 

On 07.10.22 09:41, Juergen Gross wrote:

Hello Juergen

> Use an x86-specific virtio_check_mem_acc_cb() for Xen in order to setup
> the correct DMA ops.
>
> Signed-off-by: Juergen Gross 
> ---
> V2:
> - add missing PV check in xen_virtio_mem_acc() (Oleksandr Tyshchenko)
> - add xen_virtio_restricted_mem_acc() stub (Oleksandr Tyshchenko)


Reviewed-by: Oleksandr Tyshchenko  # 
common code


> ---
>   arch/x86/xen/enlighten_hvm.c |  2 +-
>   arch/x86/xen/enlighten_pv.c  |  2 +-
>   drivers/xen/grant-dma-ops.c  | 12 +++-
>   include/xen/xen-ops.h|  6 ++
>   4 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 1c1ac418484b..c1cd28e915a3 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -212,7 +212,7 @@ static void __init xen_hvm_guest_init(void)
>   return;
>   
>   if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT))
> - virtio_set_mem_acc_cb(virtio_require_restricted_mem_acc);
> + virtio_set_mem_acc_cb(xen_virtio_restricted_mem_acc);
>   
>   init_hvm_pv_info();
>   
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 9b1a58dda935..45b24c1b646a 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -112,7 +112,7 @@ static void __init xen_pv_init_platform(void)
>   {
>   /* PV guests can't operate virtio devices without grants. */
>   if (IS_ENABLED(CONFIG_XEN_VIRTIO))
> - virtio_set_mem_acc_cb(virtio_require_restricted_mem_acc);
> + virtio_set_mem_acc_cb(xen_virtio_restricted_mem_acc);
>   
>   populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
>   
> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
> index c703b77b33c9..63c3f0dac066 100644
> --- a/drivers/xen/grant-dma-ops.c
> +++ b/drivers/xen/grant-dma-ops.c
> @@ -297,7 +297,7 @@ bool xen_is_grant_dma_device(struct device *dev)
>   
>   bool xen_virtio_mem_acc(struct virtio_device *dev)
>   {
> - if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT))
> + if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT) || xen_pv_domain())
>   return true;
>   
>   return xen_is_grant_dma_device(dev->dev.parent);
> @@ -372,6 +372,16 @@ void xen_grant_setup_dma_ops(struct device *dev)
>   dev_err(dev, "Cannot set up Xen grant DMA ops, retain platform DMA 
> ops\n");
>   }
>   
> +bool xen_virtio_restricted_mem_acc(struct virtio_device *dev)
> +{
> + bool ret = xen_virtio_mem_acc(dev);
> +
> + if (ret)
> + xen_grant_setup_dma_ops(dev->dev.parent);
> +
> + return ret;
> +}
> +
>   MODULE_DESCRIPTION("Xen grant DMA-mapping layer");
>   MODULE_AUTHOR("Juergen Gross ");
>   MODULE_LICENSE("GPL");
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index dae0f350c678..a34f4271a2e9 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -219,6 +219,7 @@ static inline void xen_preemptible_hcall_end(void) { }
>   void xen_grant_setup_dma_ops(struct device *dev);
>   bool xen_is_grant_dma_device(struct device *dev);
>   bool xen_virtio_mem_acc(struct virtio_device *dev);
> +bool xen_virtio_restricted_mem_acc(struct virtio_device *dev);
>   #else
>   static inline void xen_grant_setup_dma_ops(struct device *dev)
>   {
> @@ -234,6 +235,11 @@ static inline bool xen_virtio_mem_acc(struct 
> virtio_device *dev)
>   {
>   return false;
>   }
> +
> +static inline bool xen_virtio_restricted_mem_acc(struct virtio_device *dev)
> +{
> + return false;
> +}
>   #endif /* CONFIG_XEN_GRANT_DMA_OPS */
>   
>   #endif /* INCLUDE_XEN_OPS_H */

-- 
Regards,

Oleksandr Tyshchenko

Re: [PATCH 0/9] gnttab: further work from XSA-380 / -382 context

2022-10-07 Thread Jan Beulich 
On 26.08.2021 12:06, Jan Beulich wrote:
> The first four patches can be attributed to the former, the last four
> patches to the latter. The middle patch had been submitted standalone
> before, has a suitable Reviewed-by tag, but also has an objection by
> Andrew pending, which unfortunately has lead to this patch now being
> stuck. Short of Andrew being willing to settle the disagreement more
> with Julien than with me (although I'm on Julien's side), I have no
> idea what to do here.
> 
> There's probably not much interrelation between the patches, so they
> can perhaps go in about any order.
> 
> 1: defer allocation of maptrack frames table
> 2: drop a redundant expression from gnttab_release_mappings()
> 3: fold recurring is_iomem_page()
> 4: drop GNTMAP_can_fail
> 5: defer allocation of status frame tracking array

Just to make "official" what I've said in the course of the resource
management discussion at the event in Cambridge: I'm withdrawing 1
and 5, in the expectation that eager/lazy allocation of resources
will become a property to be honored uniformly for a guest. With 2,
3, 4, and 6 already having gone in, it would still be nice to
(finally) have feedback on ...

> 6: check handle early in gnttab_get_status_frames()
> 7: no need to translate handle for gnttab_get_status_frames()
> 8: bail from GFN-storing loops early in case of error
> 9: don't silently truncate GFNs in compat setup-table handling

... the remaining three - even if these aren't really 4.17 candidates
anymore at this point.

Thanks, Jan

Re: [PATCH] xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts

2022-10-07 Thread Oleksandr Tyshchenko 

On 07.10.22 10:15, Xenia Ragiadakou wrote:
>
> On 10/7/22 00:13, Oleksandr Tyshchenko wrote:
>
> Hi Oleksandr


Hello Xenia


>
>>
>> On 06.10.22 20:59, Xenia Ragiadakou wrote:
>>
>> Hello Xenia
>>
>>>
>>> On 10/6/22 15:09, Oleksandr Tyshchenko wrote:
 From: Oleksandr Tyshchenko 

 Although XEN_PAGE_SIZE is equal to PAGE_SIZE (4KB) for now, it would
 be more correct to use Xen specific #define-s as XEN_PAGE_SIZE can
 be changed at some point in the future.

 Signed-off-by: Oleksandr Tyshchenko 
 ---
 Cc: Juergen Gross 
 Cc: Xenia Ragiadakou 

 As it was proposed at:
 https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20221005174823.1800761-1-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!zHt-xZ_7tZc_EM6zva21E_YgwIiEeimFWfsJIpPwAu-TBcnzQhXHqlKzmXmwIcI6uIx_arHNZiaZeHt_428_8p-DyMpd$
  

 [lore[.]kernel[.]org]

 Should go in only after that series.
 ---
    drivers/xen/grant-dma-ops.c | 20 ++--
    1 file changed, 10 insertions(+), 10 deletions(-)

 diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
 index c66f56d24013..5392fdc25dca 100644
 --- a/drivers/xen/grant-dma-ops.c
 +++ b/drivers/xen/grant-dma-ops.c
 @@ -31,12 +31,12 @@ static DEFINE_XARRAY_FLAGS(xen_grant_dma_devices,
 XA_FLAGS_LOCK_IRQ);
      static inline dma_addr_t grant_to_dma(grant_ref_t grant)
    {
 -    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant << 
 PAGE_SHIFT);
 +    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
 XEN_PAGE_SHIFT);
    }
>>>
>>> With this change, can the offset added to the dma handle, generated by
>>> grant_to_dma(), be the offset in the page? Couldn't it corrupt the
>>> grant ref?
>>
>>
>> Good point, indeed, I think it could corrupt if guest uses a different
>> than Xen page granularity (i.e 64KB).
>>
>>
>>>
      static inline grant_ref_t dma_to_grant(dma_addr_t dma)
    {
 -    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
 PAGE_SHIFT);
 +    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
 XEN_PAGE_SHIFT);
    }
      static struct xen_grant_dma_data *find_xen_grant_dma_data(struct
 device *dev)
 @@ -79,7 +79,7 @@ static void *xen_grant_dma_alloc(struct device
 *dev, size_t size,
     unsigned long attrs)
    {
    struct xen_grant_dma_data *data;
 -    unsigned int i, n_pages = PFN_UP(size);
 +    unsigned int i, n_pages = XEN_PFN_UP(size);
    unsigned long pfn;
    grant_ref_t grant;
    void *ret;
 @@ -91,14 +91,14 @@ static void *xen_grant_dma_alloc(struct device
 *dev, size_t size,
    if (unlikely(data->broken))
    return NULL;
    -    ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
 +    ret = alloc_pages_exact(n_pages * XEN_PAGE_SIZE, gfp);
    if (!ret)
    return NULL;
      pfn = virt_to_pfn(ret);
      if (gnttab_alloc_grant_reference_seq(n_pages, )) {
 -    free_pages_exact(ret, n_pages * PAGE_SIZE);
 +    free_pages_exact(ret, n_pages * XEN_PAGE_SIZE);
    return NULL;
    }
    @@ -116,7 +116,7 @@ static void xen_grant_dma_free(struct device
 *dev, size_t size, void *vaddr,
   dma_addr_t dma_handle, unsigned long attrs)
    {
    struct xen_grant_dma_data *data;
 -    unsigned int i, n_pages = PFN_UP(size);
 +    unsigned int i, n_pages = XEN_PFN_UP(size);
    grant_ref_t grant;
      data = find_xen_grant_dma_data(dev);
 @@ -138,7 +138,7 @@ static void xen_grant_dma_free(struct device
 *dev, size_t size, void *vaddr,
      gnttab_free_grant_reference_seq(grant, n_pages);
    -    free_pages_exact(vaddr, n_pages * PAGE_SIZE);
 +    free_pages_exact(vaddr, n_pages * XEN_PAGE_SIZE);
    }
      static struct page *xen_grant_dma_alloc_pages(struct device *dev,
 size_t size,
 @@ -168,7 +168,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
 device *dev, struct page *page,
     unsigned long attrs)
    {
    struct xen_grant_dma_data *data;
 -    unsigned int i, n_pages = PFN_UP(offset + size);
 +    unsigned int i, n_pages = XEN_PFN_UP(offset + size);
>>>
>>> The offset, here, refers to the offset in the page ...
>>>
    grant_ref_t grant;
    dma_addr_t dma_handle;
    @@ -200,8 +200,8 @@ static void xen_grant_dma_unmap_page(struct
 device *dev, dma_addr_t dma_handle,
     unsigned long attrs)
    {
    struct xen_grant_dma_data *data;
 -    unsigned long offset = dma_handle & (PAGE_SIZE - 1);
 -    unsigned int i, n_pages = PFN_UP(offset + size);
 +    unsigned long offset = dma_handle & ~XEN_PAGE_MASK;
>>>
>>> ... while, here, it refers to the

[PATCH] xen/virtio: Handle cases when page offset > PAGE_SIZE properly

2022-10-07 Thread Oleksandr Tyshchenko 
From: Oleksandr Tyshchenko 

Passed to xen_grant_dma_map_page() offset in the page
can be > PAGE_SIZE even if the guest uses the same page granularity
as Xen (4KB).

Before current patch, if such case happened we ended up providing
grants for the whole region in xen_grant_dma_map_page() which
was really unnecessary. The more, we ended up not releasing all
grants which represented that region in xen_grant_dma_unmap_page().

Current patch updates the code to be able to deal with such cases.

Signed-off-by: Oleksandr Tyshchenko 
---
Cc: Juergen Gross 
Cc: Xenia Ragiadakou 

Depens on:
https://lore.kernel.org/xen-devel/20221005174823.1800761-1-olekst...@gmail.com/

Should go in only after that series.
---
 drivers/xen/grant-dma-ops.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index c66f56d24013..1385f0e686fe 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -168,7 +168,9 @@ static dma_addr_t xen_grant_dma_map_page(struct device 
*dev, struct page *page,
 unsigned long attrs)
 {
struct xen_grant_dma_data *data;
-   unsigned int i, n_pages = PFN_UP(offset + size);
+   unsigned long dma_offset = offset_in_page(offset),
+   gfn_offset = PFN_DOWN(offset);
+   unsigned int i, n_pages = PFN_UP(dma_offset + size);
grant_ref_t grant;
dma_addr_t dma_handle;
 
@@ -187,10 +189,10 @@ static dma_addr_t xen_grant_dma_map_page(struct device 
*dev, struct page *page,
 
for (i = 0; i < n_pages; i++) {
gnttab_grant_foreign_access_ref(grant + i, data->backend_domid,
-   xen_page_to_gfn(page) + i, dir == 
DMA_TO_DEVICE);
+   xen_page_to_gfn(page) + i + gfn_offset, dir == 
DMA_TO_DEVICE);
}
 
-   dma_handle = grant_to_dma(grant) + offset;
+   dma_handle = grant_to_dma(grant) + dma_offset;
 
return dma_handle;
 }
-- 
2.25.1

Re: [PATCH 3/3] Update Xen version to 4.17-rc

2022-10-07 Thread Julien Grall 

Hi Jan,

On 07/10/2022 12:06, Jan Beulich wrote:

On 07.10.2022 11:13, Julien Grall wrote:

From: Julien Grall 

Signed-off-by: Julien Grall 
---
  README   | 16 
  SUPPORT.md   |  2 +-
  xen/Makefile |  2 +-
  3 files changed, 10 insertions(+), 10 deletions(-)


I assume CHANGELOG.md is then going to be updated only once for the actual
release? (Not that I think that the -rc is relevant to have there, but the
version could as well be changed to 4.17.0 already now.)


In the past, this was updated once we are ready to release 4.17. I would 
prefer if we follow the same approach as it will be less error-prone and 
work.


I would otherwise have to temporarily remove the section "unstable" (to 
avoid someone mistakenly updating the changelog) and then re-introduce it.


Cheers,

--
Julien Grall

Re: [PATCH 1/3] process/release-technician-checklist: Explain how the banner in README is generated

2022-10-07 Thread Julien Grall 

Hi Jan,

On 07/10/2022 12:02, Jan Beulich wrote:

On 07.10.2022 11:13, Julien Grall wrote:

--- a/docs/process/release-technician-checklist.txt
+++ b/docs/process/release-technician-checklist.txt
@@ -49,6 +49,7 @@ t=RELEASE-$r
  * consider bumping sonames of shlibs
  
  * change xen-unstable README (should say "Xen 4.5" in releases and on stable branches, "Xen 4.5-unstable" on unstable)


This line may also want updating, to include the 4.5-rc case as well.


Good point. I will respin this patch.

Cheers,



Jan


+*   The banner is generated using figlet
  * change xen-unstable Config.mk
  #   QEMU_UPSTREAM_REVISION,
  #   QEMU_TRADITIONAL_REVISION




--
Julien Grall

[PATCH 00/19] xen/arm64: Suspend to RAM support for Xen

2022-10-07 Thread Mykyta Poturai 
This is a series from Mirela Simonovic. Ported to 4.16 and with
added changes suggested here 
https://lore.kernel.org/all/CAKPH-NjmaZENb8gT=+fobraycrf01_--6gura2ck9di5wiu...@mail.gmail.com

This series contains support for suspend to RAM (in the following text just
'suspend') for Xen on arm64. The implementation is aligned with the design
specification that has been proposed on xen-devel list:
https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg01574.html

At a high-level the series contains:
1) Support for suspending guests via virtual PSCI SYSTEM_SUSPEND call
2) Support for resuming a guest on an interrupt targeted to that guest
3) Support for suspending Xen after dom0 finalizes the suspend
4) Support for resuming Xen on an interrupt that is targeted to a guest



In more details:

*** About suspending/resuming guests

The patches included in this series allow PSCI compliant guests that have
support for suspend to RAM (e.g. echo mem > /sys/power/state in Linux) to
suspend and resume on top of Xen without any EL1 code changes.

During their suspend procedure guests will hot-unplug their secondary CPUs,
triggering Xen's virtual CPU_OFF PSCI implementation, and then finalize the
suspend from their boot CPU, triggering Xen's virtual SYSTEM_SUSPEND PSCI.
Guests will save/restore their own EL1 context on suspend/resume.

A guest is expected to leave enabled interrupts that are considered to be its
wake-up sources. Those interrupts will be able to wake up the guest. This holds
regardless of the state of the underlying software layers, i.e. whether Xen gets
suspended or not doesn't affect the ability of the guest to wake up.

First argument of SYSTEM_SUSPEND PSCI call is a resume entry point, from which
the guest assumes to start on resume. On resume, guests assume to be running in
an environment whose state matches the CPU state after reset, e.g. with reset
register values, MMU disabled, etc. To ensure this, Xen has to 'reset' the
VCPU context and save the resume entry point into program counter before the
guest's VCPU gets scheduled in on resume. This is done when the guest resumes.
Xen also needs to take care that the guest's view of GIC and timer gets saved.
Also, while a guest is suspended its watchdogs are paused, in order to avoid
watchdog triggered shutdown of a guest that has been asleep for a period of time
that is longer than the watchdog period.

After this point, from Xen's point of view a suspended guest has one VCPU
blocked, waiting for an interrupt. When such an interrupt comes, Xen will
unblock the VCPU of the suspended domain, which results in the guest
resuming.

*** About suspending/resuming Xen

Xen starts its own suspend procedure once dom0 is suspended. Dom0 is
considered to be the decision maker for EL1 and EL2.
On suspend, Xen will first freeze all domains. Then, Xen disables physical
secondary CPUs, which leads to physical CPU_OFF to be called by each secondary
CPU. After that Xen finalizes the suspend from the boot CPU.

This consists of suspending the timer, i.e. suppressing its interrupts (we don't
want to be woken up by a timer, there is no VCPU ready to be scheduled). Then
the state of GIC is saved, console is suspended, and CPU context is saved. The
saved context tells where Xen needs to continue execution on resume.
Since Xen will resume with MMU disabled, the first thing to do in resume is to
resume memory management in order to be able to access the context that needs to
be restored (we know virtual address of the context data). Finally Xen calls
SYSTEM_SUSPEND PSCI to the EL3.

When resuming, all the steps done in suspend need to be reverted. This is
completed by unblocking dom0's VCPU, because we always want the dom0 to
resume,
regardless of the target domain whose interrupt woke up Xen.

*** Handling of unprivileged guests during Xen suspend/resume

Any domU that is not suspended when dom0 suspends will be frozen, domUs that are
already suspended remain suspended. On resume the suspended domUs still remain
suspended (unless their wake interrupt caused Xen to wake) while the
others will be thawed.

For more details please refer to patches or the design specification:
https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg01574.html

Juergen Gross (1):
  xen: don't free percpu areas during suspend

Mirela Simonovic (15):
  xen/arm: Implement PSCI system suspend
  xen/arm: While a domain is suspended put its watchdogs on pause
  xen/arm: Trigger Xen suspend when Dom0 completes suspend
  xen/x86: Move freeze/thaw_domains into common files
  xen/arm: Freeze domains on suspend and thaw them on resume
  xen/arm: Disable/enable non-boot physical CPUs on suspend/resume
  xen/arm: Add rcu_barrier() before enabling non-boot CPUs on resume
  xen/arm: Implement GIC suspend/resume functions (gicv2 only)
  xen/arm: Suspend/resume GIC on system suspend/resume
  xen/arm: Suspend/resume timer

xenbits disk space "garbage collection"

2022-10-07 Thread George Dunlap 
Hello all,

The xenbits disk is getting somewhat full.  If everyone could take a minute or 
two to take a look in your own home directory and space on /people/, and delete 
anything you don’t need, that would be helpful.

`du -k -x | sort -n -r -k 1` is my normal rune for this sort of thing, if it 
helps; feel free to suggest your own if you think you have a better one. :-)

We’ll also be looking at archiving old home directories and other content, but 
it’s good for active users to do some “garbage collection” of their own 
occasionally as well.

Thanks!
 -George


signature.asc
Description: Message signed with OpenPGP

[RFC PATCH v2 1/2] xen/memory : Add a stats_table resource type

2022-10-07 Thread Matias Ezequiel Vara Larsen 
This commit proposes a new mechanism to query the RUNSTATE_running counter for
a given vcpu from a dom0 userspace application. This commit proposes to expose
that counter by using the acquire_resource interface. The current mechanism
relies on the XEN_DOMCTL_getvcpuinfo and holds a single global domctl_lock for
the entire hypercall; and iterate over every vcpu in the system for every
update thus impacting operations that share that lock.

This commit proposes to expose vcpu RUNSTATE_running via the
xenforeignmemory interface thus preventing to issue the hypercall and holding
the lock. For that purpose, a new resource type named stats_table is added. The
first frame of this resource stores per-vcpu counters. The frame has one entry
of type struct vcpu_stats per vcpu. The allocation of this frame only happens
if the resource is requested. The frame is released after the domain is
destroyed.

Note that the updating of this counter is in a hot path, thus, in this commit,
copying only happens if it is specifically required.

Note that the exposed structure is extensible in two ways. First, the structure
vcpu_stats can be extended with new per-vcpu counters while it fits in a frame.
Second, new frames can be added in case new counters are required.

Signed-off-by: Matias Ezequiel Vara Larsen 
---
Changes in v2:
- rework to ensure that guest reads a coherent value by using a version
  number in the vcpu_stats structure
- add version to the vcpu_stats structure

Changes in v1:
- rework the allocation and releasing of the frames
- use the zero frame for per-vcpu counters that are listed as an array
- allocate vcpu stats frames only when the resource is requested
- rewrite commit message
- add the vcpu_stats structure to keep per-vcpu counters
- add the shared_vcpustatspage to keep an array of per-vcpu counters for a
  given domain
- declare the structures in a public header 
- define the vcpustats_page in the domain structure
---
 xen/arch/x86/hvm/hvm.c  |  2 +
 xen/common/memory.c | 94 +
 xen/common/sched/core.c | 16 +++
 xen/include/public/memory.h |  3 ++
 xen/include/public/vcpu.h   | 16 +++
 xen/include/xen/mm.h|  2 +
 xen/include/xen/sched.h |  5 ++
 7 files changed, 138 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ddd001a6ad..1ef6cb5ff0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -741,6 +741,8 @@ void hvm_domain_relinquish_resources(struct domain *d)
 
 ioreq_server_destroy_all(d);
 
+stats_free_vcpu_mfn(d);
+
 msixtbl_pt_cleanup(d);
 
 /* Stop all asynchronous timer actions. */
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 297b98a562..749486d5d4 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1078,6 +1078,12 @@ unsigned int ioreq_server_max_frames(const struct domain 
*d)
 return nr;
 }
 
+unsigned int stats_table_max_frames(const struct domain *d)
+{
+/* One frame per 512 vcpus. */
+return 1;
+}
+
 /*
  * Return 0 on any kind of error.  Caller converts to -EINVAL.
  *
@@ -1099,6 +1105,9 @@ static unsigned int resource_max_frames(const struct 
domain *d,
 case XENMEM_resource_vmtrace_buf:
 return d->vmtrace_size >> PAGE_SHIFT;
 
+case XENMEM_resource_stats_table:
+return stats_table_max_frames(d);
+
 default:
 return -EOPNOTSUPP;
 }
@@ -1162,6 +1171,88 @@ static int acquire_vmtrace_buf(
 return nr_frames;
 }
 
+void stats_free_vcpu_mfn(struct domain * d)
+{
+struct page_info *pg = d->vcpustats_page.pg;
+
+if ( !pg )
+return;
+
+d->vcpustats_page.pg = NULL;
+
+if ( d->vcpustats_page.va )
+unmap_domain_page_global(d->vcpustats_page.va);
+
+d->vcpustats_page.va = NULL;
+
+put_page_alloc_ref(pg);
+put_page_and_type(pg);
+}
+
+static int stats_vcpu_alloc_mfn(struct domain *d)
+{
+struct page_info *pg;
+
+pg = alloc_domheap_page(d, MEMF_no_refcount);
+
+if ( !pg )
+return -ENOMEM;
+
+if ( !get_page_and_type(pg, d, PGT_writable_page) ) {
+put_page_alloc_ref(pg);
+return -ENODATA;
+}
+
+d->vcpustats_page.va = __map_domain_page_global(pg);
+if ( !d->vcpustats_page.va )
+goto fail;
+
+d->vcpustats_page.pg = pg;
+clear_page(d->vcpustats_page.va);
+return 1;
+
+fail:
+put_page_alloc_ref(pg);
+put_page_and_type(pg);
+
+return -ENOMEM;
+}
+
+static int acquire_stats_table(struct domain *d,
+unsigned int id,
+unsigned int frame,
+unsigned int nr_frames,
+xen_pfn_t mfn_list[])
+{
+mfn_t mfn;
+int rc;
+unsigned int i;
+
+if ( !d )
+return -ENOENT;
+
+for ( i = 0; i < nr_frames; i++ )
+{
+switch ( i )
+{
+case XENMEM_resource_stats_frame_vcpustats:
+if ( !d->vcpustats_page.pg

[RFC PATCH v2 2/2] tools/misc: Add xen-vcpus-stats tool

2022-10-07 Thread Matias Ezequiel Vara Larsen 
Add a demonstration tool that uses the stats_table resource to
query vcpus' RUNSTATE_running counter for a DomU.

Signed-off-by: Matias Ezequiel Vara Larsen 
---
Changes in v2:
- use period instead of frec
- rely on version to ensure reading is coherent 

Changes in v1:
- change the name of the tool to xen-vcpus-stats
- set command line parameters in the same order that are passed
- remove header libs.h
- build by default
- remove errno, strerrno, "\n", and identation
- use errx when errno is not needed
- address better the number of pages requested and error msgs
- use the shared_vcpustatspage_t structure
- use the correct frame id when requesting the resource
---
 tools/misc/Makefile  |  6 +++
 tools/misc/xen-vcpus-stats.c | 87 
 2 files changed, 93 insertions(+)
 create mode 100644 tools/misc/xen-vcpus-stats.c

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 2b683819d4..837e4b50da 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -49,6 +49,7 @@ TARGETS_COPY += xenpvnetboot
 
 # Everything which needs to be built
 TARGETS_BUILD := $(filter-out $(TARGETS_COPY),$(TARGETS_ALL))
+TARGETS_BUILD += xen-vcpus-stats
 
 # ... including build-only targets
 TARGETS_BUILD-$(CONFIG_X86)+= xen-vmtrace
@@ -135,4 +136,9 @@ xencov: xencov.o
 xen-ucode: xen-ucode.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+xen-vcpus-stats.o: CFLAGS += $(CFLAGS_libxenforeginmemory)
+
+xen-vcpus-stats: xen-vcpus-stats.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenforeignmemory) $(APPEND_LDFLAGS)
+
 -include $(DEPS_INCLUDE)
diff --git a/tools/misc/xen-vcpus-stats.c b/tools/misc/xen-vcpus-stats.c
new file mode 100644
index 00..29d0efb124
--- /dev/null
+++ b/tools/misc/xen-vcpus-stats.c
@@ -0,0 +1,87 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define rmb()   asm volatile("lfence":::"memory")
+
+static sig_atomic_t interrupted;
+static void close_handler(int signum)
+{
+interrupted = 1;
+}
+
+int main(int argc, char **argv)
+{
+xenforeignmemory_handle *fh;
+xenforeignmemory_resource_handle *res;
+size_t size;
+int rc, domid, period, vcpu;
+shared_vcpustatspage_t * info;
+struct sigaction act;
+uint32_t version;
+uint64_t value;
+
+if (argc != 4 ) {
+fprintf(stderr, "Usage: %s   \n", argv[0]);
+return 1;
+}
+
+domid = atoi(argv[1]);
+vcpu = atoi(argv[2]);
+period = atoi(argv[3]);
+
+act.sa_handler = close_handler;
+act.sa_flags = 0;
+sigemptyset(_mask);
+sigaction(SIGHUP,  , NULL);
+sigaction(SIGTERM, , NULL);
+sigaction(SIGINT,  , NULL);
+sigaction(SIGALRM, , NULL);
+
+fh = xenforeignmemory_open(NULL, 0);
+
+if ( !fh )
+err(1, "xenforeignmemory_open");
+
+rc = xenforeignmemory_resource_size(
+fh, domid, XENMEM_resource_stats_table,
+0, );
+
+if ( rc )
+err(1, "Fail: Get size");
+
+res = xenforeignmemory_map_resource(
+fh, domid, XENMEM_resource_stats_table,
+0, XENMEM_resource_stats_frame_vcpustats, size >> XC_PAGE_SHIFT,
+(void **), PROT_READ, 0);
+
+if ( !res )
+err(1, "Fail: Map");
+
+while ( !interrupted ) {
+sleep(period);
+do {
+version = info->vcpu_info[vcpu].version;
+rmb();
+value = info->vcpu_info[vcpu].runstate_running_time;
+rmb();
+} while ((info->vcpu_info[vcpu].version & 1) ||
+(version != info->vcpu_info[vcpu].version));
+printf("running_vcpu_time[%d]: %ld\n", vcpu, value);
+}
+
+rc = xenforeignmemory_unmap_resource(fh, res);
+if ( rc )
+err(1, "Fail: Unmap");
+
+return 0;
+}
-- 
2.25.1

[RFC PATCH v2 0/2] Add a new acquire resource to query vcpu statistics

2022-10-07 Thread Matias Ezequiel Vara Larsen 
Hello all,

The purpose of this RFC is to get feedback about a new acquire resource that
exposes vcpu statistics for a given domain. The current mechanism to get those
statistics is by querying the hypervisor. This mechanism relies on a hypercall
and holds the domctl spinlock during its execution. When a pv tool like xcp-rrdd
periodically samples these counters, it ends up affecting other paths that share
that spinlock. By using acquire resources, the pv tool only requires a few
hypercalls to set the shared memory region and samples are got without issuing
any other hypercall. The original idea has been suggested by Andrew Cooper to
which I have been discussing about how to implement the current PoC. You can
find the RFC patch series at [1]. The series is rebased on top of stable-4.15.

I am currently a bit blocked on 1) what to expose and 2) how to expose it. For
1), I decided to expose what xcp-rrdd is querying, e.g., XEN_DOMCTL_getvcpuinfo.
More precisely, xcp-rrd gets runstate.time[RUNSTATE_running]. This is a uint64_t
counter. However, the time spent in other states may be interesting too.
Regarding 2), I am not sure if simply using an array of uint64_t is enough or if
a different interface should be exposed. The remaining question is when to get
new values. For the moment, I am updating this counter during
vcpu_runstate_change().

The current series includes a simple pv tool that shows how this new interface 
is
used. This tool maps the counter and periodically samples it.

Any feedback/help would be appreciated.

Thanks, Matias.

[1] https://github.com/MatiasVara/xen/tree/feature_stats

Changes in v2:
- rework to ensure that consumer fetches consistent data

Changes in v1:
- rework how the resource is allocated and released
- rework when the resource is allocated that happens only when the resource is
  requested 
- rework the structure shared between the tool and Xen to make it extensible to
  new counters and declare it in a public header

There are still the following questions:
   - resource shall be released when there are no more readers otherwise we keep
 updating it during a hot path
   - one frame can host up to 512 vcpus. Should I check to this limit when
 updating? Should it be possible to allocate more than one frame for vcpu
 counters? 

Matias Ezequiel Vara Larsen (2):
  xen/memory : Add a stats_table resource type
  tools/misc: Add xen-vcpus-stats tool

 tools/misc/Makefile  |  6 +++
 tools/misc/xen-vcpus-stats.c | 87 +
 xen/arch/x86/hvm/hvm.c   |  2 +
 xen/common/memory.c  | 94 
 xen/common/sched/core.c  | 16 ++
 xen/include/public/memory.h  |  3 ++
 xen/include/public/vcpu.h| 16 ++
 xen/include/xen/mm.h |  2 +
 xen/include/xen/sched.h  |  5 ++
 9 files changed, 231 insertions(+)
 create mode 100644 tools/misc/xen-vcpus-stats.c

-- 
2.25.1

[xen-unstable test] 173452: tolerable FAIL

2022-10-07 Thread osstest service owner 
flight 173452 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173452/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-install fail pass in 173436
 test-amd64-amd64-libvirt-xsm 20 guest-start/debian.repeat  fail pass in 173436

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

Re: xen ovmf/uefi firmware does not save screen resolution

2022-10-07 Thread Chuck Zmudzinski 
On 10/6/2022 9:38 AM, Liberalia Tempus, S.L. wrote:
> Thank you very much for your answers.
>
> Finally, after trying some of the solutions proposed by Chuck, I have 
> made the decision to delete the UEFI partition and move it to a normal 
> MBR system.

Did you know you can keep the GPT partitions and the EFI partition and boot HVM 
guests
using MBR (seabios) with a GPT BIOS Boot partition present in the guest's 
virtual boot disk?
I implemented that by stealing the last 1 MB of the EFI GPT partition and 
assigned that 1 MB
to be a BIOS boot GPT partition, and grub2 is smart enough to install its own 
MBR bootcode
into that partition and it works fine in Xen HVMs by using seabios instead of 
ovmf as the
firmware/bios for the guest in the xl.cfg guest configuration file. But that's 
not necessary if
you are going to give up on using the EFI partition and GPT partitions and go 
back to the
legacy MBR partitioning scheme. What you are doing is a sensible option also 
given Xen's
current lack of support for UEFI booting of Xen HVM guests that actually works.

> I think it's too cumbersome all this xen and UEFI booting stuff and 
> there's no point in spending more time on it. At the end of the day what 
> matters in a virtual environment is that the machine works, regardless 
> of the system used to boot.
> As of today, UEFI booting does not work properly in xen/qemu, at least 
> not for people who are not experts in xen code.
> Best regards.
>
> PS: Chuck, what you say about version 4.14 I have not been able to apply 
> in a vm with windows 10. It seems to work with a hvm vm with linux, but 
> not with a windows vm.

That may be true, because I have only tried UEFI booting of a Linux HVM guest. 
I have always
used MBR booting of Windows HVM guests with either the stdvga Qemu emulated 
graphics
device as the Windows HVM guest's primary graphics device or VGA passthrough of 
the Intel
IGD graphics device to the HVM Windows guest as the guest's primary graphics 
device.

I will in the meantime try to get UEFI booting working for both Windows and 
Linux HVM guests
for the future and at the same time use the BIOS boot GPT partition hack to 
give me the option to
use MBR booting with seabios instead of ovmf as the firmware/bios for the HVM 
guest until
Xen works well enough with UEFI booting of HVM guests. Obviously the MBR 
technology is legacy
tech and Xen needs to eventually be updated to support the UEFI booting method 
of HVM guests
going forward. I am not aware of much work in this area being done by the Xen 
developers, but
I am not subscribed to xen-devel so I could be wrong about that and I would 
welcome any
Xen developer who could explain to Xen users what work is being done to support 
UEFI booting
of Xen HVM guests in the future.

Best regards,

Chuck

>
> -
> MhBeyle __
> > Date: Thu, 22 Sep 2022 11:25:41 -0400
> > From: Chuck Zmudzinski 
> >
> >
> > On 9/22/2022 4:37 AM, mhbe...@yahoo.es wrote:
> >> Thanks for the answers.
> >>
> >> Chuck, I tried at the time to apply suggested patches to the software
> >> with no results. It is not clear that any of the current patches solve
> >> the problem.
> >>
> >> I think there are two problems here: One, the virtual machine that
> >> creates xen uses QEMU and the UEFI bios is not able to communicate the
> >> resolution data to the system. Two, this kind of problem would be easily
> >> solved by virtualizing a more modern vga instead of the current cards
> >> (cirrus etc.)
> > Actually, this might be a bug in Xen 4.16 that was not in Xen 4.14.
> >
> > On Debian 11 (bullseye/stable for Dom0) booting HVM with Tiano Core
> > UEFI works for me using vga = stdvga and videoram = 16:
> >
> > With Debian 11.x stable for dom0, the Xen version is 4.14 and the Qemu
> > version is a bit old, 5.2, but booting with ovmf/uefi works:
> >
> > I boot Debian 11.x (stable) in a Xen HVM using ovmf using vga = stdvga in 
> > the
> > xl.cfg and it seems to work in a VNC window. I can get 1920x1080 resolution
> > (with videoram = 16 in the xl.cfg), but this only works on Debian stable 
> > dom0
> > with Xen version 4.14.x and Qemu version 5.1 (haven't checked if Debian
> > backported Qemu version 7.0 for Debian 11 also works).
> >
> > After login, use the gnome display settings and it gives the option of up
> > to 1920x1080 resolution with videoram = 16. I presume KDE, XFCE, MATE, etc.
> > also would allow this.
> >
> > It is true the Tiano Core UEFI boot configuration setup screen and the grub
> > screen resolution is low (I think only 800x600) at the beginning of booting.
> >
> > Here is my xl config for ovmf (UEFI booting with vga = stdvga, videoram = 
> > 16)
> > and a VNC display and Debian stable with Xen 4.14.x dom0 and Qemu 5.2 in
> > dom0 on Debian stable:
> >
> > --- domain configuration file ---
> > builder = 'hvm'
> > bios = 'ovmf'
> > memory = '6144'
> > vcpus = '4'
> > disk = ['/dev/linux/bullseye,,xvda,w']
> > name = 'bullseye-hvm'
> > vif = [

[libvirt test] 173453: tolerable all pass - PUSHED

2022-10-07 Thread osstest service owner 
flight 173453 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173453/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 173438
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 173438
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 173438
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail 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-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  491d918502e50bf15c75d183bb41e3c0de5a0e1b
baseline version:
 libvirt  25c473348bc141a82f821a2701e18f9705346a1c

Last test of basis   173438  2022-10-06 04:20:29 Z1 days
Testing same since   173453  2022-10-07 04:20:17 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Erik Skultety 
  Peter Krempa 

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  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-arm64-arm64-libvirt-raw pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-libvirt-vhd 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

Re: [PATCH 17/19] xen: don't free percpu areas during suspend

2022-10-07 Thread Juergen Gross 

On 07.10.22 12:32, Mykyta Poturai wrote:

From: Juergen Gross 

Instead of freeing percpu areas during suspend and allocating them
again when resuming keep them. Only free an area in case a cpu didn't
come up again when resuming.

It should be noted that there is a potential change in behaviour as
the percpu areas are no longer zeroed out during suspend/resume. While
I have checked the called cpu notifier hooks to cope with that there
might be some well hidden dependency on the previous behaviour. OTOH
a component not registering itself for cpu down/up and expecting to
see a zeroed percpu variable after suspend/resume is kind of broken
already. And the opposite case, where a component is not registered
to be called for cpu down/up and is not expecting a percpu variable
suddenly to be zero due to suspend/resume is much more probable,
especially as the suspend/resume functionality seems not to be tested
that often.

Signed-off-by: Juergen Gross 


I can't remember having written this patch. The one I remember was for
x86.


Reviewed-by: Dario Faggioli 


I doubt that, reasoning see above.


Juergen


---
  xen/arch/arm/percpu.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/percpu.c b/xen/arch/arm/percpu.c
index 25442c48fe..0642705544 100644
--- a/xen/arch/arm/percpu.c
+++ b/xen/arch/arm/percpu.c
@@ -58,10 +58,13 @@ static int cpu_percpu_callback(
  switch ( action )
  {
  case CPU_UP_PREPARE:
+  if ( system_state != SYS_STATE_resume )
  rc = init_percpu_area(cpu);
  break;
  case CPU_UP_CANCELED:
  case CPU_DEAD:
+case CPU_RESUME_FAILED:
+  if ( system_state != SYS_STATE_suspend )
  free_percpu_area(cpu);
  break;
  default:




OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 3/3] Update Xen version to 4.17-rc

2022-10-07 Thread Jan Beulich 
On 07.10.2022 11:13, Julien Grall wrote:
> From: Julien Grall 
> 
> Signed-off-by: Julien Grall 
> ---
>  README   | 16 
>  SUPPORT.md   |  2 +-
>  xen/Makefile |  2 +-
>  3 files changed, 10 insertions(+), 10 deletions(-)

I assume CHANGELOG.md is then going to be updated only once for the actual
release? (Not that I think that the -rc is relevant to have there, but the
version could as well be changed to 4.17.0 already now.)

Jan

Re: [PATCH 1/3] process/release-technician-checklist: Explain how the banner in README is generated

2022-10-07 Thread Jan Beulich 
On 07.10.2022 11:13, Julien Grall wrote:
> --- a/docs/process/release-technician-checklist.txt
> +++ b/docs/process/release-technician-checklist.txt
> @@ -49,6 +49,7 @@ t=RELEASE-$r
>  * consider bumping sonames of shlibs
>  
>  * change xen-unstable README (should say "Xen 4.5" in releases and on stable 
> branches, "Xen 4.5-unstable" on unstable)

This line may also want updating, to include the 4.5-rc case as well.

Jan

> +*   The banner is generated using figlet
>  * change xen-unstable Config.mk
>  #   QEMU_UPSTREAM_REVISION,
>  #   QEMU_TRADITIONAL_REVISION

Re: [PATCH 01/19] xen/arm: Implement PSCI system suspend

2022-10-07 Thread Julien Grall 

Hi Mykyta,

I couldn't find any cover letter for this series in neither my inbox nor 
xen-devel. Can you provide one explain the goal of this series (you seem 
to have a mix of domain suspend and host suspend)? If it is also based 
on an existing series, then it would be nice to mention it (this would 
be helpful to look at the existings and check if they were addressed).


Also, we are currently in the middle of the code freeze. So the review 
will likely be quite slow until 4.17 is out and I caught up with the 
rest of my backlog.


That said from a brief look, I see you included a patch that was merged 
around 4.12. So is this series actually based on staging?


If not, then the first step would be to rebase this series to the latest 
staging.


Cheers,

On 07/10/2022 11:32, Mykyta Poturai wrote:

From: Mirela Simonovic 

The implementation consists of:
-Adding PSCI system suspend call as new PSCI function
-Trapping PSCI system_suspend HVC
-Implementing PSCI system suspend call (virtual interface that allows
  guests to suspend themselves)

The PSCI system suspend should be called by a guest from its boot
VCPU. Non-boot VCPUs of the guest should be hot-unplugged using PSCI
CPU_OFF call prior to issuing PSCI system suspend. Interrupts that
are left enabled by the guest are assumed to be its wake-up interrupts.
Therefore, a wake-up interrupt triggers the resume of the guest. Guest
should resume regardless of the state of Xen (suspended or not).

When a guest calls PSCI system suspend the respective domain will be
suspended if the following conditions are met:
1) Given resume entry point is not invalid
2) Other (if any) VCPUs of the calling guest are hot-unplugged

If the conditions above are met the calling domain is labeled as
suspended and the calling VCPU is blocked. If nothing else wouldn't
be done the suspended domain would resume from the place where it
called PSCI system suspend. This is expected if processing of the PSCI
system suspend call fails. However, in the case of success the calling
guest should resume (continue execution after the wake-up) from the entry
point which is given as the first argument of the PSCI system suspend
call. In addition to the entry point, the guest expects to start within
the environment whose state matches the state after reset. This means
that the guest should find reset register values, MMU disabled, etc.
Thereby, the context of VCPU should be 'reset' (as if the system is
comming out of reset), the program counter should contain entry point,
which is 1st argument, and r0/x0 should contain context ID which is 2nd
argument of PSCI system suspend call. The context of VCPU is set during
resume path, to prevent it being overwritten by ctxt_switch_from after
vcpu is blocked and scheduled out.

VCPU is marked as suspended with _VPF_suspended flag. A suspended domain
will resume after the Xen receives an interrupt which is targeted to the
domain, unblocks the domain's VCPU, and schedules it in. During the
vcpu_unblock execution the VCPU is checked for VPF_suspended flag. If
the flag is present, the context of that VCPU gets cleared and entry
point/cid are set.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
Signed-off-by: Mykyta Poturai 
---
  xen/arch/arm/Makefile|   1 +
  xen/arch/arm/domain.c|   4 +
  xen/arch/arm/suspend.c   | 182 +++
  xen/arch/arm/vpsci.c |  28 +
  xen/common/sched/core.c  |   8 ++
  xen/include/asm-arm/domain.h |   3 +
  xen/include/asm-arm/perfc_defn.h |   1 +
  xen/include/asm-arm/psci.h   |   2 +
  xen/include/asm-arm/suspend.h|  17 +++
  xen/include/xen/sched.h  |   3 +
  10 files changed, 249 insertions(+)
  create mode 100644 xen/arch/arm/suspend.c
  create mode 100644 xen/include/asm-arm/suspend.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b5913c9d39..07dbbd99a3 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -49,6 +49,7 @@ obj-y += setup.o
  obj-y += shutdown.o
  obj-y += smp.o
  obj-y += smpboot.o
+obj-y += suspend.o
  obj-y += sysctl.o
  obj-y += time.o
  obj-y += traps.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 23c8b345d4..4110154bda 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -40,6 +40,8 @@
  #include 
  #include 
  
+#include 

+
  #include "vpci.h"
  #include "vuart.h"
  
@@ -101,6 +103,8 @@ static void ctxt_switch_from(struct vcpu *p)

  if ( is_idle_vcpu(p) )
  return;
  
+/* VCPU's context should not be saved if its domain is suspended */

+
  p2m_save_state(p);
  
  /* CP 15 */

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
new file mode 100644
index 00..987ba6ac11
--- /dev/null
+++ b/xen/arch/arm/suspend.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (C) 2022 EPAM Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU

[PATCH 19/19] Fix misleading indentation gcc warning

2022-10-07 Thread Mykyta Poturai 
From: Oleksandr Andrushchenko 

percpu.c: In function 'cpu_percpu_callback':
percpu.c:61:7: error: this 'if' clause does not guard... 
[-Werror=misleading-indentation]
   if ( system_state != SYS_STATE_resume )
   ^~
percpu.c:63:9: note: ...this statement, but the latter is misleadingly indented 
as if it were guarded by the 'if'
 break;
 ^
percpu.c:67:7: error: this 'if' clause does not guard... 
[-Werror=misleading-indentation]
   if ( system_state != SYS_STATE_suspend )
   ^~
percpu.c:69:9: note: ...this statement, but the latter is misleadingly indented 
as if it were guarded by the 'if'
 break;
 ^

Fixes: c3109b76d967 ("xen: don't free percpu areas during suspend")

Signed-off-by: Oleksandr Andrushchenko 
---
 xen/arch/arm/percpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/percpu.c b/xen/arch/arm/percpu.c
index 0642705544..9eab1e6d7c 100644
--- a/xen/arch/arm/percpu.c
+++ b/xen/arch/arm/percpu.c
@@ -60,13 +60,13 @@ static int cpu_percpu_callback(
 case CPU_UP_PREPARE:
   if ( system_state != SYS_STATE_resume )
 rc = init_percpu_area(cpu);
-break;
+  break;
 case CPU_UP_CANCELED:
 case CPU_DEAD:
 case CPU_RESUME_FAILED:
   if ( system_state != SYS_STATE_suspend )
 free_percpu_area(cpu);
-break;
+  break;
 default:
 break;
 }
-- 
2.37.1

[PATCH 14/19] xen/arm: Save/restore context on suspend/resume

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

The context of CPU general purpose and system control registers
has to be saved on suspend and restored on resume. This is
implemented in hyp_suspend and before the return from hyp_resume
function. The hyp_suspend is invoked just before the PSCI system
suspend call is issued to the ATF. The hyp_suspend has to return a
non-zero value so that the calling 'if' statement evaluates to true,
causing the system suspend to be invoked. Upon the resume, context
saved on suspend will be restored, including the link register.
Therefore, after restoring the context the control flow will
return to the address pointed by the saved link register, which
is the place from which the hyp_suspend was called. To ensure
that the calling 'if' statement doesn't again evaluate to true
and initiate system suspend, hyp_resume has to return a zero value
after restoring the context.
Note that the order of saving register context into cpu_context
structure has to match the order of restoring.
Since the suspend/resume is supported only for arm64, we define
a null cpu_context structure so arm32 could compile.

Update: moved hyp_resume to head.S to place it near the rest of the
start code

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/arm64/head.S | 90 ++-
 xen/arch/arm/suspend.c| 25 --
 xen/include/asm-arm/suspend.h | 22 +
 3 files changed, 133 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 82d83214dc..e2c46a864c 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -957,6 +957,53 @@ ENTRY(efi_xen_start)
 b real_start_efi
 ENDPROC(efi_xen_start)
 
+/*
+ * void hyp_suspend(struct cpu_context *ptr)
+ *
+ * x0 - pointer to the storage where callee's context will be saved
+ *
+ * CPU context saved here will be restored on resume in hyp_resume function.
+ * hyp_suspend shall return a non-zero value. Upon restoring context
+ * hyp_resume shall return value zero instead. From C code that invokes
+ * hyp_suspend, the return value is interpreted to determine whether the 
context
+ * is saved (hyp_suspend) or restored (hyp_resume).
+ */
+ENTRY(hyp_suspend)
+/* Store callee-saved registers */
+stp x19, x20, [x0], #16
+stp x21, x22, [x0], #16
+stp x23, x24, [x0], #16
+stp x25, x26, [x0], #16
+stp x27, x28, [x0], #16
+stp x29, lr, [x0], #16
+
+/* Store stack-pointer */
+mov x2, sp
+str x2, [x0], #8
+
+/* Store system control registers */
+mrs x2, VBAR_EL2
+str x2, [x0], #8
+mrs x2, VTCR_EL2
+str x2, [x0], #8
+mrs x2, VTTBR_EL2
+str x2, [x0], #8
+mrs x2, TPIDR_EL2
+str x2, [x0], #8
+mrs x2, MDCR_EL2
+str x2, [x0], #8
+mrs x2, HSTR_EL2
+str x2, [x0], #8
+mrs x2, CPTR_EL2
+str x2, [x0], #8
+mrs x2, HCR_EL2
+str x2, [x0], #8
+
+/* hyp_suspend must return a non-zero value */
+mov x0, #1
+ret
+
+
 ENTRY(hyp_resume)
 msr   DAIFSet, 0xf   /* Disable all interrupts */
 
@@ -988,7 +1035,48 @@ mmu_resumed:
 tlbi  alle2
 dsb   sy /* Ensure completion of TLB flush */
 isb
-b .
+
+/* Now we can access the cpu_context, so restore the context here */
+ldr x0, =cpu_context
+
+/* Restore callee-saved registers */
+ldp x19, x20, [x0], #16
+ldp x21, x22, [x0], #16
+ldp x23, x24, [x0], #16
+ldp x25, x26, [x0], #16
+ldp x27, x28, [x0], #16
+ldp x29, lr, [x0], #16
+
+/* Restore stack pointer */
+ldr x2, [x0], #8
+mov sp, x2
+
+/* Restore system control registers */
+ldr x2, [x0], #8
+msr VBAR_EL2, x2
+ldr x2, [x0], #8
+msr VTCR_EL2, x2
+ldr x2, [x0], #8
+msr VTTBR_EL2, x2
+ldr x2, [x0], #8
+msr TPIDR_EL2, x2
+ldr x2, [x0], #8
+msr MDCR_EL2, x2
+ldr x2, [x0], #8
+msr HSTR_EL2, x2
+ldr x2, [x0], #8
+msr CPTR_EL2, x2
+ldr x2, [x0], #8
+msr HCR_EL2, x2
+isb
+
+/* Since context is restored return from this function will appear as
+ * return from hyp_suspend. To distinguish a return from hyp_suspend
+ * which is called upon finalizing the suspend, as opposed to return
+ * from this function which executes on resume, we need to return zero
+ * value here. */
+mov x0, #0
+ret
 
 /*
  * Local variables:
diff --git a/xen/arch/arm/suspend.c

[PATCH 15/19] xen/arm: Resume Dom0 after Xen resumes

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

The resume of Dom0 should always follow Xen's resume. This is
done by unblocking the first vCPU of Dom0.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/arch/arm/suspend.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index 13d1aba658..4a690eac3b 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -206,6 +206,9 @@ resume_nonboot_cpus:
 system_state = SYS_STATE_active;
 dsb(sy);
 
+/* Wake-up hardware domain (should always resume after Xen) */
+vcpu_unblock(hardware_domain->vcpu[0]);
+
 return status;
 }
 
-- 
2.37.1

[PATCH 17/19] xen: don't free percpu areas during suspend

2022-10-07 Thread Mykyta Poturai 
From: Juergen Gross 

Instead of freeing percpu areas during suspend and allocating them
again when resuming keep them. Only free an area in case a cpu didn't
come up again when resuming.

It should be noted that there is a potential change in behaviour as
the percpu areas are no longer zeroed out during suspend/resume. While
I have checked the called cpu notifier hooks to cope with that there
might be some well hidden dependency on the previous behaviour. OTOH
a component not registering itself for cpu down/up and expecting to
see a zeroed percpu variable after suspend/resume is kind of broken
already. And the opposite case, where a component is not registered
to be called for cpu down/up and is not expecting a percpu variable
suddenly to be zero due to suspend/resume is much more probable,
especially as the suspend/resume functionality seems not to be tested
that often.

Signed-off-by: Juergen Gross 
Reviewed-by: Dario Faggioli 
---
 xen/arch/arm/percpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/percpu.c b/xen/arch/arm/percpu.c
index 25442c48fe..0642705544 100644
--- a/xen/arch/arm/percpu.c
+++ b/xen/arch/arm/percpu.c
@@ -58,10 +58,13 @@ static int cpu_percpu_callback(
 switch ( action )
 {
 case CPU_UP_PREPARE:
+  if ( system_state != SYS_STATE_resume )
 rc = init_percpu_area(cpu);
 break;
 case CPU_UP_CANCELED:
 case CPU_DEAD:
+case CPU_RESUME_FAILED:
+  if ( system_state != SYS_STATE_suspend )
 free_percpu_area(cpu);
 break;
 default:
-- 
2.37.1

[PATCH 11/19] xen/arm: Suspend/resume timer interrupt generation

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

Timer interrupts have to be disabled while the system is in suspend.
Otherwise, a timer interrupt would fire and wake-up the system.
Suspending the timer interrupts consists of disabling physical EL1
and EL2 timers. The resume consists only of raising timer softirq,
which will trigger the generic timer code to reprogram the EL2 timer
as needed. Enabling of EL1 physical timer will be triggered by an
entity which uses it.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/arch/arm/suspend.c |  4 
 xen/arch/arm/time.c| 22 ++
 xen/include/asm-arm/time.h |  3 +++
 3 files changed, 29 insertions(+)

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index b94a6df86d..05c43ce502 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -151,6 +151,8 @@ static long system_suspend(void *data)
 goto resume_nonboot_cpus;
 }
 
+time_suspend();
+
 local_irq_save(flags);
 status = gic_suspend();
 if ( status )
@@ -166,6 +168,8 @@ static long system_suspend(void *data)
 resume_irqs:
 local_irq_restore(flags);
 
+time_resume();
+
 resume_nonboot_cpus:
 rcu_barrier();
 enable_nonboot_cpus();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index dec53b5f7d..ca54bcfe68 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -363,6 +363,28 @@ void domain_set_time_offset(struct domain *d, int64_t 
time_offset_seconds)
 /* XXX update guest visible wallclock time */
 }
 
+void time_suspend(void)
+{
+/* Disable physical EL1 timer */
+WRITE_SYSREG(0, CNTP_CTL_EL0);
+
+/* Disable hypervisor's timer */
+WRITE_SYSREG(0, CNTHP_CTL_EL2);
+isb();
+}
+
+void time_resume(void)
+{
+/*
+ * Raising timer softirq will trigger generic timer code to reprogram_timer
+ * with the correct timeout value (which is not known here). There is no
+ * need to do anything else in order to recover the time keeping from power
+ * down, because the system counter is not affected by the power down (it
+ * resides out of the ARM's cluster in an always-on part of the SoC).
+ */
+raise_softirq(TIMER_SOFTIRQ);
+}
+
 static int cpu_time_callback(struct notifier_block *nfb,
  unsigned long action,
  void *hcpu)
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
index 4b401c1110..ded93b490a 100644
--- a/xen/include/asm-arm/time.h
+++ b/xen/include/asm-arm/time.h
@@ -107,6 +107,9 @@ void preinit_xen_time(void);
 
 void force_update_vcpu_system_time(struct vcpu *v);
 
+void time_suspend(void);
+void time_resume(void);
+
 #endif /* __ARM_TIME_H__ */
 /*
  * Local variables:
-- 
2.37.1

[PATCH 18/19] timers: Don't migrate timers during suspend

2022-10-07 Thread Mykyta Poturai 
Migrating timers during suspend causes Dom0 to freeze after resume.

Signed-off-by: Mykyta Poturai 
---
 xen/common/timer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/common/timer.c b/xen/common/timer.c
index 1bb265ceea..52d4f72a76 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -658,7 +658,8 @@ static int cpu_callback(
 case CPU_UP_CANCELED:
 case CPU_DEAD:
 case CPU_RESUME_FAILED:
-migrate_timers_from_cpu(cpu);
+if ( system_state != SYS_STATE_suspend )
+migrate_timers_from_cpu(cpu);
 
 if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
 free_percpu_timers(cpu);
-- 
2.37.1

[PATCH 13/19] xen/arm: Resume memory management on Xen resume

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

The MMU needs to be enabled in the resume flow before the context
can be restored (we need to be able to access the context data by
virtual address in order to restore it). The configuration of system
registers prior to branching to the routine that sets up the page
tables is copied from xen/arch/arm/arm64/head.S.
After the MMU is enabled, the content of TTBR0_EL2 is changed to
point to init_ttbr (page tables used at runtime).

At boot the init_ttbr variable is updated when a secondary CPU is
hotplugged. In the scenario where there is only one physical CPU in
the system, the init_ttbr would not be initialized for the use in
resume flow. To get the variable initialized in all scenarios in this
patch we add that the boot CPU updates init_ttbr after it sets the
page tables for runtime.

After the memory management is resumed, the SCTLR_WXN in SCTLR_EL2
has to be set in order to configure that a mapping cannot be both
writable and executable (this was configured prior to suspend).
This is done using an existing function (mmu_init_secondary_cpu).

Update: moved hyp_resume to head.S to place it near the rest of the
start code

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/arm64/entry.S  |  2 ++
 xen/arch/arm/arm64/head.S   | 30 ++
 xen/arch/arm/mm.c   |  1 +
 xen/arch/arm/suspend.c  |  6 ++
 xen/include/asm-arm/processor.h | 22 ++
 5 files changed, 61 insertions(+)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index fc3811ad0a..f49f1daf46 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -1,4 +1,6 @@
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 8857955699..82d83214dc 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -958,6 +958,36 @@ ENTRY(efi_xen_start)
 ENDPROC(efi_xen_start)
 
 ENTRY(hyp_resume)
+msr   DAIFSet, 0xf   /* Disable all interrupts */
+
+tlbi  alle2
+dsb   sy /* Ensure completion of TLB flush */
+isb
+
+ldr   x0, =start
+adr   x19, start /* x19 := paddr (start) */
+sub   x20, x19, x0   /* x20 := phys-offset */
+
+mov   x22, #0/* x22 := is_secondary_cpu */
+
+blcheck_cpu_mode
+blcpu_init
+blcreate_page_tables
+blenable_mmu
+
+ldr   x0, =mmu_resumed  /* Explicit vaddr, not RIP-relative */
+brx0/* Get a proper vaddr into PC */
+
+mmu_resumed:
+ldr   x4, =init_ttbr /* VA of TTBR0_EL2 stashed by CPU 0 */
+ldr   x4, [x4]   /* Actual value */
+dsb   sy
+msr   TTBR0_EL2, x4
+dsb   sy
+isb
+tlbi  alle2
+dsb   sy /* Ensure completion of TLB flush */
+isb
 b .
 
 /*
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index eea926d823..29cdaff3bf 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -708,6 +708,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset)
 switch_ttbr(ttbr);
 
 xen_pt_enforce_wnx();
+init_secondary_pagetables(0);
 
 #ifdef CONFIG_ARM_32
 per_cpu(xen_pgtable, 0) = cpu0_pgtable;
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index a0258befc9..aa5ee4714b 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -167,6 +167,12 @@ static long system_suspend(void *data)
 
 system_state = SYS_STATE_resume;
 
+/*
+ * SCTLR_WXN needs to be set to configure that a mapping cannot be both
+ * writable and executable. This is done by mmu_init_secondary_cpu.
+ */
+mmu_init_secondary_cpu();
+
 gic_resume();
 
 resume_irqs:
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 8ab2940f68..ecf97f1ab4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -133,6 +133,28 @@
 #define TTBCR_PD1   (_AC(1,U)<<5)
 
 /* SCTLR System Control Register. */
+/* HSCTLR is a subset of this. */
+#define SCTLR_TE(_AC(1,U)<<30)
+#define SCTLR_AFE   (_AC(1,U)<<29)
+#define SCTLR_TRE   (_AC(1,U)<<28)
+#define SCTLR_NMFI  (_AC(1,U)<<27)
+#define SCTLR_EE(_AC(1,U)<<25)
+#define SCTLR_VE(_AC(1,U)<<24)
+#define SCTLR_U (_AC(1,U)<<22)
+#define SCTLR_FI(_AC(1,U)<<21)
+#define SCTLR_WXN   (_AC(1,U)<<19)
+#define SCTLR_HA(_AC(1,U)<<17)
+#define SCTLR_RR(_AC(1,U)<<14)
+#define SCTLR_V (_AC(1,U)<<13)
+#define SCTLR_I (_AC(1,U)<<12)
+#define SCTLR_Z (_AC(1,U)<<11)
+#define SCTLR_SW(_AC(1,U)<<10)
+#define SCTLR_B (_AC(1,U)<<7)
+#define SCTLR_C (_AC(1,U)<<2)
+#define SCTLR_A (_AC(1,U)<<1)

[PATCH 12/19] xen/arm: Implement PSCI SYSTEM_SUSPEND call (physical interface)

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

PSCI system suspend function shall be invoked to finalize Xen suspend
procedure. Resume entry point, which needs to be passed via 1st argument
of PSCI system suspend call to the EL3, is hyp_resume. For now, hyp_resume
is just a placeholder that will be implemented in assembly. Context ID,
which is 2nd argument of system suspend PSCI call, is unused, as in Linux.

Update: moved hyp_resume to head.S to place it near the rest of the
start code

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/arm64/head.S |  3 +++
 xen/arch/arm/psci.c   | 16 
 xen/arch/arm/suspend.c|  4 
 xen/include/asm-arm/psci.h|  1 +
 xen/include/asm-arm/suspend.h |  1 +
 5 files changed, 25 insertions(+)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index aa1f88c764..8857955699 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -957,6 +957,9 @@ ENTRY(efi_xen_start)
 b real_start_efi
 ENDPROC(efi_xen_start)
 
+ENTRY(hyp_resume)
+b .
+
 /*
  * Local variables:
  * mode: ASM
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 0c90c2305c..43a67eb345 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * While a 64-bit OS can make calls with SMC32 calling conventions, for
@@ -68,6 +69,21 @@ void call_psci_cpu_off(void)
 }
 }
 
+int call_psci_system_suspend(void)
+{
+#ifdef CONFIG_ARM_64
+struct arm_smccc_res res;
+
+/* 2nd argument (context ID) is not used */
+arm_smccc_smc(PSCI_1_0_FN64_SYSTEM_SUSPEND, __pa(hyp_resume), );
+
+return PSCI_RET(res);
+#else
+/* not supported */
+return 1;
+#endif
+}
+
 void call_psci_system_off(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index 05c43ce502..a0258befc9 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -161,6 +161,10 @@ static long system_suspend(void *data)
 goto resume_irqs;
 }
 
+status = call_psci_system_suspend();
+if ( status )
+dprintk(XENLOG_ERR, "PSCI system suspend failed, err=%d\n", status);
+
 system_state = SYS_STATE_resume;
 
 gic_resume();
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index 26462d0c47..9f6116a224 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -20,6 +20,7 @@ extern uint32_t psci_ver;
 
 int psci_init(void);
 int call_psci_cpu_on(int cpu);
+int call_psci_system_suspend(void);
 void call_psci_cpu_off(void);
 void call_psci_system_off(void);
 void call_psci_system_reset(void);
diff --git a/xen/include/asm-arm/suspend.h b/xen/include/asm-arm/suspend.h
index fbaa414f0c..29420e27fa 100644
--- a/xen/include/asm-arm/suspend.h
+++ b/xen/include/asm-arm/suspend.h
@@ -3,6 +3,7 @@
 
 int32_t domain_suspend(register_t epoint, register_t cid);
 void vcpu_resume(struct vcpu *v);
+void hyp_resume(void);
 
 #endif
 
-- 
2.37.1

[PATCH 16/19] xen/arm: Suspend/resume console on Xen suspend/resume

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

This is done using generic console_suspend/resume functions that cause
uart driver specific suspend/resume handlers to be called for each
initialized port (if the port has suspend/resume driver handlers
implemented).

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/arch/arm/suspend.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index 4a690eac3b..cf3aab0099 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -166,6 +167,15 @@ static long system_suspend(void *data)
 goto resume_irqs;
 }
 
+dprintk(XENLOG_DEBUG, "Suspend\n");
+status = console_suspend();
+if ( status )
+{
+dprintk(XENLOG_ERR, "Failed to suspend the console, err=%d\n", status);
+system_state = SYS_STATE_resume;
+goto resume_console;
+}
+
 if ( hyp_suspend(_context) )
 {
 status = call_psci_system_suspend();
@@ -192,6 +202,10 @@ static long system_suspend(void *data)
  */
 mmu_init_secondary_cpu();
 
+resume_console:
+console_resume();
+dprintk(XENLOG_DEBUG, "Resume\n");
+
 gic_resume();
 
 resume_irqs:
-- 
2.37.1

[PATCH 08/19] xen/arm: Add rcu_barrier() before enabling non-boot CPUs on resume

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

The rcu_barrier() has to be added to ensure that the per cpu area is
freed before a non-boot CPU tries to initialize it (_free_percpu_area()
has to be called before the init_percpu_area()). This scenario occurs
when non-boot CPUs are hot-unplugged on suspend and hotplugged on resume.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/arch/arm/suspend.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index 0784979e4f..0c16cfc750 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -153,6 +153,7 @@ static long system_suspend(void *data)
 system_state = SYS_STATE_resume;
 
 resume_nonboot_cpus:
+rcu_barrier();
 enable_nonboot_cpus();
 thaw_domains();
 system_state = SYS_STATE_active;
-- 
2.37.1

[PATCH 01/19] xen/arm: Implement PSCI system suspend

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

The implementation consists of:
-Adding PSCI system suspend call as new PSCI function
-Trapping PSCI system_suspend HVC
-Implementing PSCI system suspend call (virtual interface that allows
 guests to suspend themselves)

The PSCI system suspend should be called by a guest from its boot
VCPU. Non-boot VCPUs of the guest should be hot-unplugged using PSCI
CPU_OFF call prior to issuing PSCI system suspend. Interrupts that
are left enabled by the guest are assumed to be its wake-up interrupts.
Therefore, a wake-up interrupt triggers the resume of the guest. Guest
should resume regardless of the state of Xen (suspended or not).

When a guest calls PSCI system suspend the respective domain will be
suspended if the following conditions are met:
1) Given resume entry point is not invalid
2) Other (if any) VCPUs of the calling guest are hot-unplugged

If the conditions above are met the calling domain is labeled as
suspended and the calling VCPU is blocked. If nothing else wouldn't
be done the suspended domain would resume from the place where it
called PSCI system suspend. This is expected if processing of the PSCI
system suspend call fails. However, in the case of success the calling
guest should resume (continue execution after the wake-up) from the entry
point which is given as the first argument of the PSCI system suspend
call. In addition to the entry point, the guest expects to start within
the environment whose state matches the state after reset. This means
that the guest should find reset register values, MMU disabled, etc.
Thereby, the context of VCPU should be 'reset' (as if the system is
comming out of reset), the program counter should contain entry point,
which is 1st argument, and r0/x0 should contain context ID which is 2nd
argument of PSCI system suspend call. The context of VCPU is set during
resume path, to prevent it being overwritten by ctxt_switch_from after
vcpu is blocked and scheduled out.

VCPU is marked as suspended with _VPF_suspended flag. A suspended domain
will resume after the Xen receives an interrupt which is targeted to the
domain, unblocks the domain's VCPU, and schedules it in. During the
vcpu_unblock execution the VCPU is checked for VPF_suspended flag. If
the flag is present, the context of that VCPU gets cleared and entry
point/cid are set.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/Makefile|   1 +
 xen/arch/arm/domain.c|   4 +
 xen/arch/arm/suspend.c   | 182 +++
 xen/arch/arm/vpsci.c |  28 +
 xen/common/sched/core.c  |   8 ++
 xen/include/asm-arm/domain.h |   3 +
 xen/include/asm-arm/perfc_defn.h |   1 +
 xen/include/asm-arm/psci.h   |   2 +
 xen/include/asm-arm/suspend.h|  17 +++
 xen/include/xen/sched.h  |   3 +
 10 files changed, 249 insertions(+)
 create mode 100644 xen/arch/arm/suspend.c
 create mode 100644 xen/include/asm-arm/suspend.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b5913c9d39..07dbbd99a3 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -49,6 +49,7 @@ obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
 obj-y += smpboot.o
+obj-y += suspend.o
 obj-y += sysctl.o
 obj-y += time.o
 obj-y += traps.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 23c8b345d4..4110154bda 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -40,6 +40,8 @@
 #include 
 #include 
 
+#include 
+
 #include "vpci.h"
 #include "vuart.h"
 
@@ -101,6 +103,8 @@ static void ctxt_switch_from(struct vcpu *p)
 if ( is_idle_vcpu(p) )
 return;
 
+/* VCPU's context should not be saved if its domain is suspended */
+
 p2m_save_state(p);
 
 /* CP 15 */
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
new file mode 100644
index 00..987ba6ac11
--- /dev/null
+++ b/xen/arch/arm/suspend.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (C) 2022 EPAM Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct cpu_context cpu_context;
+
+/* Reset values of VCPU architecture specific registers */
+static void vcpu_arch_reset(struct vcpu *v)
+{
+v->arch.ttbr0 = 0;
+v->arch.ttbr1 = 0;
+v->arch.ttbcr = 0;
+
+v->arch.csselr = 0;
+v->arch.cpacr = 0;
+v->arch.contextidr = 0;
+v->arch.tpidr_el0 = 0;
+

[PATCH 10/19] xen/arm: Suspend/resume GIC on system suspend/resume

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

GIC state is saved on system suspend by calling gic_suspend
(this function does not change current state of the GIC but only
saves the values of configuration registers).
The state of GIC has to be restored by calling gic_resume, but only
if the gic_suspend has succeeded. If gic_suspend fails, we'll just
restore interrupts configuration and abort suspend.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/arch/arm/gic.c |  4 +---
 xen/arch/arm/suspend.c | 14 ++
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index e9feb1fd3b..ef90664929 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -476,9 +476,7 @@ int gic_suspend(void)
 if ( !gic_hw_ops->suspend || !gic_hw_ops->resume )
 return -ENOSYS;
 
-gic_hw_ops->suspend();
-
-return 0;
+return gic_hw_ops->suspend();
 }
 
 void gic_resume(void)
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index 0c16cfc750..b94a6df86d 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -137,6 +137,7 @@ void vcpu_resume(struct vcpu *v)
 static long system_suspend(void *data)
 {
 int status;
+unsigned long flags;
 
 BUG_ON(system_state != SYS_STATE_active);
 
@@ -150,8 +151,21 @@ static long system_suspend(void *data)
 goto resume_nonboot_cpus;
 }
 
+local_irq_save(flags);
+status = gic_suspend();
+if ( status )
+{
+system_state = SYS_STATE_resume;
+goto resume_irqs;
+}
+
 system_state = SYS_STATE_resume;
 
+gic_resume();
+
+resume_irqs:
+local_irq_restore(flags);
+
 resume_nonboot_cpus:
 rcu_barrier();
 enable_nonboot_cpus();
-- 
2.37.1

[PATCH 06/19] xen/arm: Freeze domains on suspend and thaw them on resume

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

Freeze and thaw of domains is reused as implemented for x86. In
addition, system_state variable is updated to represent the actual
state of the system.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/arch/arm/suspend.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index b09bf319d0..2b94816b63 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -137,6 +137,14 @@ static long system_suspend(void *data)
 {
 BUG_ON(system_state != SYS_STATE_active);
 
+system_state = SYS_STATE_suspend;
+freeze_domains();
+
+system_state = SYS_STATE_resume;
+
+thaw_domains();
+system_state = SYS_STATE_active;
+
 return -ENOSYS;
 }
 
-- 
2.37.1

[PATCH 07/19] xen/arm: Disable/enable non-boot physical CPUs on suspend/resume

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

Non-boot CPUs have to be disabled on suspend and enabled on resume
(hotplug-based mechanism). Disabling non-boot CPUs will lead to PSCI
CPU_OFF to be called by each non-boot CPU. Depending on the underlying
platform capabilities, this may lead to the physical powering down of
CPUs. Tested on Xilinx Zynq Ultrascale+ MPSoC (including power down of
each non-boot CPU).

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/arch/arm/suspend.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index 2b94816b63..0784979e4f 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -135,17 +136,29 @@ void vcpu_resume(struct vcpu *v)
 /* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */
 static long system_suspend(void *data)
 {
+int status;
+
 BUG_ON(system_state != SYS_STATE_active);
 
 system_state = SYS_STATE_suspend;
 freeze_domains();
 
+status = disable_nonboot_cpus();
+if ( status )
+{
+system_state = SYS_STATE_resume;
+goto resume_nonboot_cpus;
+}
+
 system_state = SYS_STATE_resume;
 
+resume_nonboot_cpus:
+enable_nonboot_cpus();
 thaw_domains();
 system_state = SYS_STATE_active;
+dsb(sy);
 
-return -ENOSYS;
+return status;
 }
 
 int32_t domain_suspend(register_t epoint, register_t cid)
-- 
2.37.1

[PATCH 09/19] xen/arm: Implement GIC suspend/resume functions (gicv2 only)

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

System suspend may lead to a state where GIC would be powered down.
Therefore, Xen should save/restore the context of GIC on suspend/resume.
Note that the context consists of states of registers which are
controlled by the hypervisor. Other GIC registers which are accessible
by guests are saved/restored on context switch.
Tested on Xilinx Ultrascale+ MPSoC with (and without) powering down
the GIC.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/arch/arm/gic-v2.c | 138 +-
 xen/arch/arm/gic.c|  27 
 xen/include/asm-arm/gic.h |   8 +++
 3 files changed, 172 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index b2adc8ec9a..b077b66d92 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -123,6 +123,23 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 #define NR_GIC_CPU_IF 8
 
+/* GICv2 registers to be saved/restored on system suspend/resume */
+struct gicv2_context {
+/* GICC context */
+uint32_t gicc_ctlr;
+uint32_t gicc_pmr;
+uint32_t gicc_bpr;
+/* GICD context */
+uint32_t gicd_ctlr;
+uint32_t *gicd_isenabler;
+uint32_t *gicd_isactiver;
+uint32_t *gicd_ipriorityr;
+uint32_t *gicd_itargetsr;
+uint32_t *gicd_icfgr;
+};
+
+static struct gicv2_context gicv2_context;
+
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
 writeb_relaxed(val, gicv2.map_dbase + offset);
@@ -1251,6 +1268,40 @@ static void __init gicv2_acpi_init(void)
 static void __init gicv2_acpi_init(void) { }
 #endif
 
+static int gicv2_alloc_context(struct gicv2_context *gc)
+{
+uint32_t n = gicv2_info.nr_lines;
+
+gc->gicd_isenabler = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32));
+if ( !gc->gicd_isenabler )
+goto err_free;
+
+gc->gicd_isactiver = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32));
+if ( !gc->gicd_isactiver )
+goto err_free;
+
+gc->gicd_itargetsr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4));
+if ( !gc->gicd_itargetsr )
+goto err_free;
+
+gc->gicd_ipriorityr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4));
+if ( !gc->gicd_ipriorityr )
+goto err_free;
+
+gc->gicd_icfgr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 16));
+if ( !gc->gicd_icfgr )
+goto err_free;
+
+return 0;
+err_free:
+xfree(gc->gicd_icfgr);
+xfree(gc->gicd_ipriorityr);
+xfree(gc->gicd_itargetsr);
+xfree(gc->gicd_isactiver);
+xfree(gc->gicd_isenabler);
+return -ENOMEM;
+}
+
 static int __init gicv2_init(void)
 {
 uint32_t aliased_offset = 0;
@@ -1318,7 +1369,8 @@ static int __init gicv2_init(void)
 
 spin_unlock();
 
-return 0;
+/* Allocate memory to be used for saving GIC context during the suspend */
+return gicv2_alloc_context(_context);
 }
 
 static void gicv2_do_LPI(unsigned int lpi)
@@ -1327,6 +1379,88 @@ static void gicv2_do_LPI(unsigned int lpi)
 BUG();
 }
 
+static int gicv2_suspend(void)
+{
+int i;
+
+ASSERT(gicv2_context.gicd_isenabler);
+ASSERT(gicv2_context.gicd_isactiver);
+ASSERT(gicv2_context.gicd_ipriorityr);
+ASSERT(gicv2_context.gicd_itargetsr);
+ASSERT(gicv2_context.gicd_icfgr);
+
+/* Save GICC configuration */
+gicv2_context.gicc_ctlr = readl_gicc(GICC_CTLR);
+gicv2_context.gicc_pmr = readl_gicc(GICC_PMR);
+gicv2_context.gicc_bpr = readl_gicc(GICC_BPR);
+
+/* Save GICD configuration */
+gicv2_context.gicd_ctlr = readl_gicd(GICD_CTLR);
+
+for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ )
+gicv2_context.gicd_isenabler[i] = readl_gicd(GICD_ISENABLER + i * 4);
+
+for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ )
+gicv2_context.gicd_isactiver[i] = readl_gicd(GICD_ISACTIVER + i * 4);
+
+for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
+gicv2_context.gicd_ipriorityr[i] = readl_gicd(GICD_IPRIORITYR + i * 4);
+
+for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
+gicv2_context.gicd_itargetsr[i] = readl_gicd(GICD_ITARGETSR + i * 4);
+
+for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 16); i++ )
+gicv2_context.gicd_icfgr[i] = readl_gicd(GICD_ICFGR + i * 4);
+
+return 0;
+}
+
+static void gicv2_resume(void)
+{
+int i;
+
+ASSERT(gicv2_context.gicd_isenabler);
+ASSERT(gicv2_context.gicd_isactiver);
+ASSERT(gicv2_context.gicd_ipriorityr);
+ASSERT(gicv2_context.gicd_itargetsr);
+ASSERT(gicv2_context.gicd_icfgr);
+
+/* Disable CPU interface and distributor */
+writel_gicc(0, GICC_CTLR);
+writel_gicd(0, GICD_CTLR);
+
+/* Restore GICD configuration */
+for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ ) {
+writel_gicd(0x, GICD_ICENABLER + i * 4);
+writel_gicd(gicv2_context.gicd_isenabler[i], GICD_ISENABLER + i * 4);
+}
+
+for ( i = 0; i <

[PATCH 05/19] xen/x86: Move freeze/thaw_domains into common files

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

These functions will be reused by suspend/resume support for ARM.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
---
 xen/common/domain.c | 29 +
 xen/include/xen/sched.h |  3 +++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 56d47dd664..5e5894c468 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1884,6 +1884,35 @@ int continue_hypercall_on_cpu(
 return 0;
 }
 
+
+void freeze_domains(void)
+{
+struct domain *d;
+
+rcu_read_lock(_read_lock);
+/*
+ * Note that we iterate in order of domain-id. Hence we will pause dom0
+ * first which is required for correctness (as only dom0 can add domains to
+ * the domain list). Otherwise we could miss concurrently-created domains.
+ */
+for_each_domain ( d )
+domain_pause(d);
+rcu_read_unlock(_read_lock);
+}
+
+void thaw_domains(void)
+{
+struct domain *d;
+
+rcu_read_lock(_read_lock);
+for_each_domain ( d )
+{
+restore_vcpu_affinity(d);
+domain_unpause(d);
+}
+rcu_read_unlock(_read_lock);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 00a939aa01..c8ddfdd51c 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -978,6 +978,9 @@ static inline struct vcpu *domain_vcpu(const struct domain 
*d,
 return vcpu_id >= d->max_vcpus ? NULL : d->vcpu[idx];
 }
 
+void freeze_domains(void);
+void thaw_domains(void);
+
 void cpu_init(void);
 
 /*
-- 
2.37.1

[PATCH 04/19] xen/arm: Trigger Xen suspend when Dom0 completes suspend

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

When Dom0 finalizes its suspend procedure the suspend of Xen is
triggered by calling system_suspend(). Dom0 finalizes the suspend from
its boot core (VCPU#0), which could be mapped to any physical CPU,
i.e. the system_suspend() function could be executed by any physical
CPU. Since Xen suspend procedure has to be run by the boot CPU
(non-boot CPUs will be disabled at some point in suspend procedure),
system_suspend() execution has to continue on CPU#0.

Though it is not clearly stated that the PSCI suspend call should be
issued from cpu0, we assume that it is to simplify the process. This
assumption is based on a fact that most platforms call some form of
disable_nonboot_cpus routine before issuing the PSCI suspend call.

When the system_suspend() returns 0, it means that the system was
suspended and it is coming out of the resume procedure. Regardless
of the system_suspend() return value, after this function returns
Xen is fully functional, and its state, including all devices and data
structures, matches the state prior to calling system_suspend().
The status is returned by system_suspend() for debugging/logging
purposes and function prototype compatibility.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/suspend.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index d19545744f..b09bf319d0 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -132,11 +132,20 @@ void vcpu_resume(struct vcpu *v)
 clear_bit(_VPF_suspended, >pause_flags);
 }
 
+/* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */
+static long system_suspend(void *data)
+{
+BUG_ON(system_state != SYS_STATE_active);
+
+return -ENOSYS;
+}
+
 int32_t domain_suspend(register_t epoint, register_t cid)
 {
 struct vcpu *v;
 struct domain *d = current->domain;
 bool is_thumb = epoint & 1;
+int status;
 
 dprintk(XENLOG_DEBUG,
 "Dom%d suspend: epoint=0x%"PRIregister", cid=0x%"PRIregister"\n",
@@ -173,6 +182,31 @@ int32_t domain_suspend(register_t epoint, register_t cid)
  */
 vcpu_block_unless_event_pending(current);
 
+/* If this was dom0 the whole system should suspend: trigger Xen suspend */
+if ( is_hardware_domain(d) )
+{
+/*
+ * system_suspend should be called when Dom0 finalizes the suspend
+ * procedure from its boot core (VCPU#0). However, Dom0's VCPU#0 could
+ * be mapped to any PCPU (this function could be executed by any PCPU).
+ * The suspend procedure has to be finalized by the PCPU#0 (non-boot
+ * PCPUs will be disabled during the suspend).
+ */
+status = continue_hypercall_on_cpu(0, system_suspend, NULL);
+/*
+ * If an error happened, there is nothing that needs to be done here
+ * because the system_suspend always returns in fully functional state
+ * no matter what the outcome of suspend procedure is. If the system
+ * suspended successfully the function will return 0 after the resume.
+ * Otherwise, if an error is returned it means Xen did not suspended,
+ * but it is still in the same state as if the system_suspend was never
+ * called. We dump a debug message in case of an error for debugging/
+ * logging purpose.
+ */
+if ( status )
+dprintk(XENLOG_ERR, "Failed to suspend, errno=%d\n", status);
+}
+
 return PSCI_SUCCESS;
 }
 
-- 
2.37.1

[PATCH 03/19] xen/arm: While a domain is suspended put its watchdogs on pause

2022-10-07 Thread Mykyta Poturai 
From: Mirela Simonovic 

While a domain is suspended its watchdogs must be paused. Otherwise,
if the domain stays in the suspend state for a longer period of time
compared to the watchdog period, the domain would be shutdown on resume.
Proper solution to this problem is to stop (suspend) the watchdog timers
after the domain suspends and to restart (resume) the watchdog timers
before the domain resumes. The suspend/resume of watchdog timers is done
in Xen and is invisible to the guests.
Just before the domain starts resuming the watchdog timers are programmed
with a new expire value. The new expire value is set according to the
last offset provided by the last hypercall before suspend was triggered,
effectively restarting the timer.

Signed-off-by: Mirela Simonovic 
Signed-off-by: Saeed Nowshadi 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/suspend.c  |  4 
 xen/common/sched/core.c | 36 
 xen/include/xen/sched.h |  7 +++
 3 files changed, 47 insertions(+)

diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index 987ba6ac11..d19545744f 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -128,6 +128,7 @@ void vcpu_resume(struct vcpu *v)
 
 /* Initialize VCPU registers */
 arch_set_info_guest(v, );
+watchdog_domain_resume(v->domain);
 clear_bit(_VPF_suspended, >pause_flags);
 }
 
@@ -162,6 +163,9 @@ int32_t domain_suspend(register_t epoint, register_t cid)
  */
 vcpu_suspend(epoint, cid);
 
+/* Disable watchdogs of this domain */
+watchdog_domain_suspend(d);
+
 /*
  * The calling domain is suspended by blocking its last running VCPU. If an
  * event is pending the domain will resume right away (VCPU will not block,
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 0ecb41cfe1..ebed0ec49e 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -1616,6 +1616,42 @@ void watchdog_domain_destroy(struct domain *d)
 kill_timer(>watchdog_timer[i].timer);
 }
 
+void watchdog_domain_suspend(struct domain *d)
+{
+unsigned int i;
+
+spin_lock(>watchdog_lock);
+
+for ( i = 0; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ )
+{
+if ( test_bit(i, >watchdog_inuse_map) )
+{
+stop_timer(>watchdog_timer[i].timer);
+}
+}
+
+spin_unlock(>watchdog_lock);
+}
+
+void watchdog_domain_resume(struct domain *d)
+{
+unsigned int i;
+
+spin_lock(>watchdog_lock);
+
+for ( i = 0; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ )
+{
+if ( test_bit(i, >watchdog_inuse_map) )
+{
+set_timer(>watchdog_timer[i].timer,
+  NOW() + SECONDS(d->watchdog_timer[i].timeout));
+}
+}
+
+spin_unlock(>watchdog_lock);
+}
+
+
 /*
  * Pin a vcpu temporarily to a specific CPU (or restore old pinning state if
  * cpu is NR_CPUS).
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 7a4aef4c17..00a939aa01 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1025,6 +1025,13 @@ void scheduler_disable(void);
 void watchdog_domain_init(struct domain *d);
 void watchdog_domain_destroy(struct domain *d);
 
+/*
+ * Suspend/resume watchdogs of domain (while the domain is suspended its
+ * watchdogs should be on pause)
+ */
+void watchdog_domain_suspend(struct domain *d);
+void watchdog_domain_resume(struct domain *d);
+
 /*
  * Use this check when the following are both true:
  *  - Using this feature or interface requires full access to the hardware
-- 
2.37.1

[PATCH 02/19] watchdog: Introduce a separate struct for watchdog timers

2022-10-07 Thread Mykyta Poturai 
This change is needed to properly implement the suspend/resume actions
for the watchdog timers. To be able to restart watchdog timer after
suspend we need to remember their frequency somewhere. To not bloat the
struct timer a new struct watchdog_timer is introduced, containing the
original timer and the last set timeout.

Signed-off-by: Mykyta Poturai 
---
 xen/common/keyhandler.c|  2 +-
 xen/common/sched/core.c| 11 ++-
 xen/include/xen/sched.h|  3 ++-
 xen/include/xen/watchdog.h |  6 ++
 4 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 8b9f378371..e9bd48fa5b 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -289,7 +289,7 @@ static void dump_domains(unsigned char key)
 for ( i = 0 ; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ )
 if ( test_bit(i, >watchdog_inuse_map) )
 printk("watchdog %d expires in %d seconds\n",
-   i, (u32)((d->watchdog_timer[i].expires - NOW()) >> 30));
+   i, (u32)((d->watchdog_timer[i].timer.expires - NOW()) 
>> 30));
 
 arch_dump_domain_info(d);
 
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 4e1ea62c44..0ecb41cfe1 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -1567,7 +1567,8 @@ static long domain_watchdog(struct domain *d, uint32_t 
id, uint32_t timeout)
 {
 if ( test_and_set_bit(id, >watchdog_inuse_map) )
 continue;
-set_timer(>watchdog_timer[id], NOW() + SECONDS(timeout));
+d->watchdog_timer[id].timeout = timeout;
+set_timer(>watchdog_timer[id].timer, NOW() + SECONDS(timeout));
 break;
 }
 spin_unlock(>watchdog_lock);
@@ -1583,12 +1584,12 @@ static long domain_watchdog(struct domain *d, uint32_t 
id, uint32_t timeout)
 
 if ( timeout == 0 )
 {
-stop_timer(>watchdog_timer[id]);
+stop_timer(>watchdog_timer[id].timer);
 clear_bit(id, >watchdog_inuse_map);
 }
 else
 {
-set_timer(>watchdog_timer[id], NOW() + SECONDS(timeout));
+set_timer(>watchdog_timer[id].timer, NOW() + SECONDS(timeout));
 }
 
 spin_unlock(>watchdog_lock);
@@ -1604,7 +1605,7 @@ void watchdog_domain_init(struct domain *d)
 d->watchdog_inuse_map = 0;
 
 for ( i = 0; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ )
-init_timer(>watchdog_timer[i], domain_watchdog_timeout, d, 0);
+init_timer(>watchdog_timer[i].timer, domain_watchdog_timeout, d, 0);
 }
 
 void watchdog_domain_destroy(struct domain *d)
@@ -1612,7 +1613,7 @@ void watchdog_domain_destroy(struct domain *d)
 unsigned int i;
 
 for ( i = 0; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ )
-kill_timer(>watchdog_timer[i]);
+kill_timer(>watchdog_timer[i].timer);
 }
 
 /*
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b2f6d1af28..7a4aef4c17 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -517,7 +518,7 @@ struct domain
 #define NR_DOMAIN_WATCHDOG_TIMERS 2
 spinlock_t watchdog_lock;
 uint32_t watchdog_inuse_map;
-struct timer watchdog_timer[NR_DOMAIN_WATCHDOG_TIMERS];
+struct watchdog_timer watchdog_timer[NR_DOMAIN_WATCHDOG_TIMERS];
 
 struct rcu_head rcu;
 
diff --git a/xen/include/xen/watchdog.h b/xen/include/xen/watchdog.h
index 86fde0884a..3398dcba37 100644
--- a/xen/include/xen/watchdog.h
+++ b/xen/include/xen/watchdog.h
@@ -8,6 +8,12 @@
 #define __XEN_WATCHDOG_H__
 
 #include 
+#include 
+
+struct watchdog_timer {
+struct timer timer;
+uint32_t timeout;
+};
 
 #ifdef CONFIG_WATCHDOG
 
-- 
2.37.1

RE: [PATCH 3/3] Update Xen version to 4.17-rc

2022-10-07 Thread Henry Wang 
Hi Julien,

> -Original Message-
> From: Julien Grall 
> Subject: Re: [PATCH 3/3] Update Xen version to 4.17-rc
> On 07/10/2022 10:51, Henry Wang wrote:
> > Hi Julien,
> 
> Hi Henry,
> 
> >> -Original Message-
> >> From: Julien Grall 
> >> Subject: [PATCH 3/3] Update Xen version to 4.17-rc
> >>
> >> From: Julien Grall 
> >>
> >> Signed-off-by: Julien Grall 
> >
> > I am not very sure, but I think the name should be 4.17-rc1 since
> > we will likely to have rc2 to rc4 according to the previous plan in
> > xen-devel [1]?
> 
> Looking at previous release, we are not updating the files for every RC.
> Instead, we only tag the commit with X-rc.

Ah, my bad, sorry for the noise then.

Release-acked-by: Henry Wang 

Kind regards,
Henry

> 
> Cheers,
> 
> --
> Julien Grall

Re: [PATCH 3/3] Update Xen version to 4.17-rc

2022-10-07 Thread Julien Grall 




On 07/10/2022 10:51, Henry Wang wrote:

Hi Julien,


Hi Henry,


-Original Message-
From: Julien Grall 
Subject: [PATCH 3/3] Update Xen version to 4.17-rc

From: Julien Grall 

Signed-off-by: Julien Grall 


I am not very sure, but I think the name should be 4.17-rc1 since
we will likely to have rc2 to rc4 according to the previous plan in
xen-devel [1]?


Looking at previous release, we are not updating the files for every RC. 
Instead, we only tag the commit with X-rc.


Cheers,

--
Julien Grall

RE: [PATCH 3/3] Update Xen version to 4.17-rc

2022-10-07 Thread Henry Wang 
Hi Julien,

> -Original Message-
> From: Julien Grall 
> Subject: [PATCH 3/3] Update Xen version to 4.17-rc
> 
> From: Julien Grall 
> 
> Signed-off-by: Julien Grall 

I am not very sure, but I think the name should be 4.17-rc1 since
we will likely to have rc2 to rc4 according to the previous plan in
xen-devel [1]?

[1] 
https://lore.kernel.org/xen-devel/as8pr08mb7991dd9e3e7c966e9c6dca0392...@as8pr08mb7991.eurprd08.prod.outlook.com/

Kind regards,
Henry

> ---
>  README   | 16 
>  SUPPORT.md   |  2 +-
>  xen/Makefile |  2 +-
>  3 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/README b/README
> index 89a1d0b43c4c..2fdca8861bef 100644
> --- a/README
> +++ b/README
> @@ -1,11 +1,11 @@
> -
> -__  ____ _
> -\ \/ /___ _ ___   _ _ __  ___| |_ __ _| |__ | | ___
> - \  // _ \ '_ \ _| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
> - /  \  __/ | | |_| |_| | | | \__ \ || (_| | |_) | |  __/
> -/_/\_\___|_| |_|  \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
> -
> -
> +###
> +__  ___  __ _
> +\ \/ /___ _ __   | || |  / |___  |_ __ ___
> + \  // _ \ '_ \  | || |_ | |  / /| '__/ __|
> + /  \  __/ | | | |__   _|| | / /_| | | (__
> +/_/\_\___|_| |_||_|(_)_|/_/  |_|  \___|
> +
> +###
> 
>  https://www.xen.org/
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 29f74ac5063e..cf2ddfacaf09 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
> 
>  # Release Support
> 
> -Xen-Version: unstable
> +Xen-Version: 4.17-rc
>  Initial-Release: n/a
>  Supported-Until: TBD
>  Security-Support-Until: Unreleased - not yet security-supported
> diff --git a/xen/Makefile b/xen/Makefile
> index 4e6e661261ae..9d0df5e2c543 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
>  # All other places this is stored (eg. compile.h) should be autogenerated.
>  export XEN_VERSION   = 4
>  export XEN_SUBVERSION= 17
> -export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
> +export XEN_EXTRAVERSION ?= -rc$(XEN_VENDORVERSION)
>  export XEN_FULLVERSION   =
> $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
>  -include xen-version
> 
> --
> 2.37.1

RE: [PATCH 2/3] Config.mk pin QEMU_UPSTREAM_REVISION (prep for Xen 4.17 RC1)

2022-10-07 Thread Henry Wang 
Hi Julien,

> -Original Message-
> From: Julien Grall 
> Subject: [PATCH 2/3] Config.mk pin QEMU_UPSTREAM_REVISION (prep for
> Xen 4.17 RC1)
> 
> From: Julien Grall 
> 
> Signed-off-by: Julien Grall 

Release-acked-by: Henry Wang 

Kind regards,
Henry

Re: [PATCH 1/3] process/release-technician-checklist: Explain how the banner in README is generated

2022-10-07 Thread Juergen Gross 

On 07.10.22 11:13, Julien Grall wrote:

From: Julien Grall 

Signed-off-by: Julien Grall 


Reviewed-by: Juergen Gross 


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

RE: [PATCH 1/3] process/release-technician-checklist: Explain how the banner in README is generated

2022-10-07 Thread Henry Wang 
Hi Julien,

> -Original Message-
> From: Julien Grall 
> Subject: [PATCH 1/3] process/release-technician-checklist: Explain how the
> banner in README is generated
> 
> From: Julien Grall 
> 
> Signed-off-by: Julien Grall 

Release-acked-by: Henry Wang 

Kind regards,
Henry

[PATCH 2/3] Config.mk pin QEMU_UPSTREAM_REVISION (prep for Xen 4.17 RC1)

2022-10-07 Thread Julien Grall 
From: Julien Grall 

Signed-off-by: Julien Grall 
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 69af1e60d4cc..e0ce59346896 100644
--- a/Config.mk
+++ b/Config.mk
@@ -229,7 +229,7 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= 7b4a99be8a39c12d3a7fc4b8db9f0eab4ac688d5
-QEMU_UPSTREAM_REVISION ?= master
+QEMU_UPSTREAM_REVISION ?= b746458e1ce1bec85e58b458386f8b7a0bedfaa6
 MINIOS_UPSTREAM_REVISION ?= 5bcb28aaeba1c2506a82fab0cdad0201cd9b54b3
 
 SEABIOS_UPSTREAM_REVISION ?= rel-1.16.0
-- 
2.37.1

[PATCH 1/3] process/release-technician-checklist: Explain how the banner in README is generated

2022-10-07 Thread Julien Grall 
From: Julien Grall 

Signed-off-by: Julien Grall 
---
 docs/process/release-technician-checklist.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/process/release-technician-checklist.txt 
b/docs/process/release-technician-checklist.txt
index 7515da202c92..914f31959ab0 100644
--- a/docs/process/release-technician-checklist.txt
+++ b/docs/process/release-technician-checklist.txt
@@ -49,6 +49,7 @@ t=RELEASE-$r
 * consider bumping sonames of shlibs
 
 * change xen-unstable README (should say "Xen 4.5" in releases and on stable 
branches, "Xen 4.5-unstable" on unstable)
+*   The banner is generated using figlet
 * change xen-unstable Config.mk
 #   QEMU_UPSTREAM_REVISION,
 #   QEMU_TRADITIONAL_REVISION
-- 
2.37.1

[PATCH 3/3] Update Xen version to 4.17-rc

2022-10-07 Thread Julien Grall 
From: Julien Grall 

Signed-off-by: Julien Grall 
---
 README   | 16 
 SUPPORT.md   |  2 +-
 xen/Makefile |  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/README b/README
index 89a1d0b43c4c..2fdca8861bef 100644
--- a/README
+++ b/README
@@ -1,11 +1,11 @@
-
-__  ____ _
-\ \/ /___ _ ___   _ _ __  ___| |_ __ _| |__ | | ___
- \  // _ \ '_ \ _| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
- /  \  __/ | | |_| |_| | | | \__ \ || (_| | |_) | |  __/
-/_/\_\___|_| |_|  \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
-
-
+###
+__  ___  __ _
+\ \/ /___ _ __   | || |  / |___  |_ __ ___
+ \  // _ \ '_ \  | || |_ | |  / /| '__/ __|
+ /  \  __/ | | | |__   _|| | / /_| | | (__
+/_/\_\___|_| |_||_|(_)_|/_/  |_|  \___|
+
+###
 
 https://www.xen.org/
 
diff --git a/SUPPORT.md b/SUPPORT.md
index 29f74ac5063e..cf2ddfacaf09 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
 
 # Release Support
 
-Xen-Version: unstable
+Xen-Version: 4.17-rc
 Initial-Release: n/a
 Supported-Until: TBD
 Security-Support-Until: Unreleased - not yet security-supported
diff --git a/xen/Makefile b/xen/Makefile
index 4e6e661261ae..9d0df5e2c543 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST))
 # All other places this is stored (eg. compile.h) should be autogenerated.
 export XEN_VERSION   = 4
 export XEN_SUBVERSION= 17
-export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
+export XEN_EXTRAVERSION ?= -rc$(XEN_VENDORVERSION)
 export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 -include xen-version
 
-- 
2.37.1

[PATCH 0/3] Prepare the tree for 4.17 RC

2022-10-07 Thread Julien Grall 
From: Julien Grall 

Hi all,

This small series is to get the tree ready for cutting the first
4.17 release candidate.

I haven't prepared any RC in the past. So I mainly followed the
guideline in docs/process/release-technician-checklist.txt. Please
let me know if I missed anything.

Cheers,

Julien Grall (3):
  process/release-technician-checklist: Explain how the banner in README
is generated
  Config.mk pin QEMU_UPSTREAM_REVISION (prep for Xen 4.17 RC1)
  Update Xen version to 4.17-rc

 Config.mk |  2 +-
 README| 16 
 SUPPORT.md|  2 +-
 docs/process/release-technician-checklist.txt |  1 +
 xen/Makefile  |  2 +-
 5 files changed, 12 insertions(+), 11 deletions(-)

-- 
2.37.1

[linux-linus test] 173451: tolerable FAIL - PUSHED

2022-10-07 Thread osstest service owner 
flight 173451 linux-linus real [real]
flight 173455 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173451/
http://logs.test-lab.xenproject.org/osstest/logs/173455/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  8 xen-bootfail pass in 173455-retest

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

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

version targeted for testing:
 linuxffb39098bf87db327b2be4b5c6f1087bcba94ce9
baseline version:
 linux833477fce7a14d43ae4c07f8ddc32fa5119471a2

Last test of basis   173442  2022-10-06 07:53:50 Z1 days
Testing same since   173451  2022-10-06 21:13:17 Z0 days1 attempts


321 people touched revisions under test,
not listing them all

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

Re: [PATCH] ImageBuilder: Add support for 64-bit addresses

2022-10-07 Thread Michal Orzel 
Hi Stefano,

On 07/10/2022 00:34, Stefano Stabellini wrote:
> 
> 
> +xen-devel
> 
> On Thu, 6 Oct 2022, Michal Orzel wrote:
>> At the moment, ImageBuilder assumes that all addresses/sizes are
>> 32-bit max. It sets #{address,size}-cells to 0x2 and puts 0x0 as the
>> value for the first cell. Because of that, we cannot specify MEMORY_START
>> and MEMORY_END to be above 32-bits (e.g. to place the images in the
>> upper memory bank).
>>
>> Add support to properly handle 64-bit addresses:
>>  - add function split_into_halves to split the value passed as a first
>>argument into upper and lower halves. These are then set as values for
>>variables passed respetively as the second and third argument,
>>  - whenever there is a variable storing the full 64-bit number with
>>"addr" or "size" in name, introduce two additional variables with
>>"addr1,addr2"/"size1,size2" in name to store the halves. These are
>>then used to properly set cells.
>>
>> Signed-off-by: Michal Orzel 
>>
>> ---
>>  scripts/uboot-script-gen | 60 +++-
>>  1 file changed, 53 insertions(+), 7 deletions(-)
>>
>> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
>> index 16269f02f1e7..4c6525a910f3 100755
>> --- a/scripts/uboot-script-gen
>> +++ b/scripts/uboot-script-gen
>> @@ -25,6 +25,14 @@ function dt_mknode()
>>  fi
>>  }
>>
>> +# Usage:
>> +# split_into_halves   
>> 
>> +function split_into_halves()
>> +{
>> +eval "$2=$(printf "0x%X\n" $(($1 >> 32)))"
>> +eval "$3=$(printf "0x%X\n" $(($1 & 0x)))"
>> +}
> 
> I know it is the same thing, but I would prefer the following version
> because it makes it easier to read:
> 
> # Usage:
> # split_into_halves   
> 
> function split_into_halves()
> {
> local value=$1
> local upper=$2
> local lower=$3
> 
> eval "$upper=$(printf "0x%X\n" $(($value >> 32)))"
> eval "$lower=$(printf "0x%X\n" $(($value & 0x)))"
> }
That is ok for me.

> 
> 
>> +
>>  # data_type is either
>>  #   int
>>  #   hex
>> @@ -41,10 +49,14 @@ function dt_set()
>>
>>  if test $data_type = "var"
>>  then
>> -eval data_addr_var="$data"_addr
>> -eval data_addr=\$"$data_addr_var"
>> -eval data_size_var="$data"_size
>> -eval data_size=\$"$data_size_var"
>> +eval data_addr1_var="$data"_addr1
>> +eval data_addr2_var="$data"_addr2
>> +eval data_addr1=\$"$data_addr1_var"
>> +eval data_addr2=\$"$data_addr2_var"
>> +eval data_size1_var="$data"_size1
>> +eval data_size2_var="$data"_size2
>> +eval data_size1=\$"$data_size1_var"
>> +eval data_size2=\$"$data_size2_var"
> 
> To avoid making the code more complex, is it possible to stick with just
> a single data_addr variable in u-boot and calculate the upper and lower
> 32-bit using u-boot commands?
The reason why we need these extra variables is to add them into respective
cells under different nodes. In dt_set we need to put the variable names
for dynamic assignment and variable values for static assignment. We cannot
do this having a single pair data_addr_var,data_addr. These evals corresponds
to variables from xen_file_loading. dt_set and add_size are two different
functions. The former is used to create the nodes and the latter is used to
set values for the environment variables.

Example:
dt_set "/chosen/dom0" "reg" "var" "dom0_linux"
- this will create a reg property for dom0 kernel. We need to insert the upper
and lower halves into this property (so we need separate variables for that)
e.g.
reg <0x${dom0_linux_addr1} 0x${dom0_linux_addr2} 0x${dom0_linux_size1} 
0x${dom0_linux_size2}>

load_file $DOM0_KERNEL "dom0_linux" calling add_size
- this will set values for upper and lower halves into u-boot env variables
that corresponds to variables we placed previously in reg property,
e.g.
setenv dom0_linux_addr1 ${memaddr1}
setenv dom0_linux_addr2 ${memaddr2}
setenv dom0_linux_size1 ${filesize1}
setenv dom0_linux_size2 ${filesize2}

FWICS, we cannot achieve this using a single pair.

~Michal

Re: [PATCH] xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts

2022-10-07 Thread Xenia Ragiadakou 



On 10/7/22 00:13, Oleksandr Tyshchenko wrote:

Hi Oleksandr



On 06.10.22 20:59, Xenia Ragiadakou wrote:

Hello Xenia



On 10/6/22 15:09, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Although XEN_PAGE_SIZE is equal to PAGE_SIZE (4KB) for now, it would
be more correct to use Xen specific #define-s as XEN_PAGE_SIZE can
be changed at some point in the future.

Signed-off-by: Oleksandr Tyshchenko 
---
Cc: Juergen Gross 
Cc: Xenia Ragiadakou 

As it was proposed at:
https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20221005174823.1800761-1-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!zHt-xZ_7tZc_EM6zva21E_YgwIiEeimFWfsJIpPwAu-TBcnzQhXHqlKzmXmwIcI6uIx_arHNZiaZeHt_428_8p-DyMpd$
[lore[.]kernel[.]org]

Should go in only after that series.
---
   drivers/xen/grant-dma-ops.c | 20 ++--
   1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index c66f56d24013..5392fdc25dca 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -31,12 +31,12 @@ static DEFINE_XARRAY_FLAGS(xen_grant_dma_devices,
XA_FLAGS_LOCK_IRQ);
     static inline dma_addr_t grant_to_dma(grant_ref_t grant)
   {
-    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant << PAGE_SHIFT);
+    return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
XEN_PAGE_SHIFT);
   }


With this change, can the offset added to the dma handle, generated by
grant_to_dma(), be the offset in the page? Couldn't it corrupt the
grant ref?



Good point, indeed, I think it could corrupt if guest uses a different
than Xen page granularity (i.e 64KB).





     static inline grant_ref_t dma_to_grant(dma_addr_t dma)
   {
-    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
PAGE_SHIFT);
+    return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
XEN_PAGE_SHIFT);
   }
     static struct xen_grant_dma_data *find_xen_grant_dma_data(struct
device *dev)
@@ -79,7 +79,7 @@ static void *xen_grant_dma_alloc(struct device
*dev, size_t size,
    unsigned long attrs)
   {
   struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(size);
+    unsigned int i, n_pages = XEN_PFN_UP(size);
   unsigned long pfn;
   grant_ref_t grant;
   void *ret;
@@ -91,14 +91,14 @@ static void *xen_grant_dma_alloc(struct device
*dev, size_t size,
   if (unlikely(data->broken))
   return NULL;
   -    ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
+    ret = alloc_pages_exact(n_pages * XEN_PAGE_SIZE, gfp);
   if (!ret)
   return NULL;
     pfn = virt_to_pfn(ret);
     if (gnttab_alloc_grant_reference_seq(n_pages, )) {
-    free_pages_exact(ret, n_pages * PAGE_SIZE);
+    free_pages_exact(ret, n_pages * XEN_PAGE_SIZE);
   return NULL;
   }
   @@ -116,7 +116,7 @@ static void xen_grant_dma_free(struct device
*dev, size_t size, void *vaddr,
  dma_addr_t dma_handle, unsigned long attrs)
   {
   struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(size);
+    unsigned int i, n_pages = XEN_PFN_UP(size);
   grant_ref_t grant;
     data = find_xen_grant_dma_data(dev);
@@ -138,7 +138,7 @@ static void xen_grant_dma_free(struct device
*dev, size_t size, void *vaddr,
     gnttab_free_grant_reference_seq(grant, n_pages);
   -    free_pages_exact(vaddr, n_pages * PAGE_SIZE);
+    free_pages_exact(vaddr, n_pages * XEN_PAGE_SIZE);
   }
     static struct page *xen_grant_dma_alloc_pages(struct device *dev,
size_t size,
@@ -168,7 +168,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
device *dev, struct page *page,
    unsigned long attrs)
   {
   struct xen_grant_dma_data *data;
-    unsigned int i, n_pages = PFN_UP(offset + size);
+    unsigned int i, n_pages = XEN_PFN_UP(offset + size);


The offset, here, refers to the offset in the page ...


   grant_ref_t grant;
   dma_addr_t dma_handle;
   @@ -200,8 +200,8 @@ static void xen_grant_dma_unmap_page(struct
device *dev, dma_addr_t dma_handle,
    unsigned long attrs)
   {
   struct xen_grant_dma_data *data;
-    unsigned long offset = dma_handle & (PAGE_SIZE - 1);
-    unsigned int i, n_pages = PFN_UP(offset + size);
+    unsigned long offset = dma_handle & ~XEN_PAGE_MASK;


... while, here, it refers to the offset in the grant.
So, the calculated number of grants may differ.


Good point, I think you are right, so we need to additionally use
xen_offset_in_page() macro in xen_grant_dma_map_page(),

something like that to be squashed with current patch:


diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 9d5eca6d638a..bb984dc05deb 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -169,7 +169,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
device *dev, struct page *page,
   unsigned long attrs)
   {
      struct xen_grant_dma_data

[PATCH v2 2/3] xen/virtio: use dom0 as default backend for CONFIG_XEN_VIRTIO_FORCE_GRANT

2022-10-07 Thread Juergen Gross 
With CONFIG_XEN_VIRTIO_FORCE_GRANT set the default backend domid to 0,
enabling to use xen_grant_dma_ops for those devices.

Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Acked-by: Stefano Stabellini 
---
 drivers/xen/grant-dma-ops.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 646ca913c05c..c703b77b33c9 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -349,6 +349,9 @@ void xen_grant_setup_dma_ops(struct device *dev)
if (dev->of_node) {
if (xen_dt_grant_init_backend_domid(dev, data))
goto err;
+   } else if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT)) {
+   dev_info(dev, "Using dom0 as backend\n");
+   data->backend_domid = 0;
} else {
/* XXX ACPI device unsupported for now */
goto err;
-- 
2.35.3

[PATCH v2 3/3] xen/virtio: enable grant based virtio on x86

2022-10-07 Thread Juergen Gross 
Use an x86-specific virtio_check_mem_acc_cb() for Xen in order to setup
the correct DMA ops.

Signed-off-by: Juergen Gross 
---
V2:
- add missing PV check in xen_virtio_mem_acc() (Oleksandr Tyshchenko)
- add xen_virtio_restricted_mem_acc() stub (Oleksandr Tyshchenko)
---
 arch/x86/xen/enlighten_hvm.c |  2 +-
 arch/x86/xen/enlighten_pv.c  |  2 +-
 drivers/xen/grant-dma-ops.c  | 12 +++-
 include/xen/xen-ops.h|  6 ++
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 1c1ac418484b..c1cd28e915a3 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -212,7 +212,7 @@ static void __init xen_hvm_guest_init(void)
return;
 
if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT))
-   virtio_set_mem_acc_cb(virtio_require_restricted_mem_acc);
+   virtio_set_mem_acc_cb(xen_virtio_restricted_mem_acc);
 
init_hvm_pv_info();
 
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 9b1a58dda935..45b24c1b646a 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -112,7 +112,7 @@ static void __init xen_pv_init_platform(void)
 {
/* PV guests can't operate virtio devices without grants. */
if (IS_ENABLED(CONFIG_XEN_VIRTIO))
-   virtio_set_mem_acc_cb(virtio_require_restricted_mem_acc);
+   virtio_set_mem_acc_cb(xen_virtio_restricted_mem_acc);
 
populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
 
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index c703b77b33c9..63c3f0dac066 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -297,7 +297,7 @@ bool xen_is_grant_dma_device(struct device *dev)
 
 bool xen_virtio_mem_acc(struct virtio_device *dev)
 {
-   if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT))
+   if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT) || xen_pv_domain())
return true;
 
return xen_is_grant_dma_device(dev->dev.parent);
@@ -372,6 +372,16 @@ void xen_grant_setup_dma_ops(struct device *dev)
dev_err(dev, "Cannot set up Xen grant DMA ops, retain platform DMA 
ops\n");
 }
 
+bool xen_virtio_restricted_mem_acc(struct virtio_device *dev)
+{
+   bool ret = xen_virtio_mem_acc(dev);
+
+   if (ret)
+   xen_grant_setup_dma_ops(dev->dev.parent);
+
+   return ret;
+}
+
 MODULE_DESCRIPTION("Xen grant DMA-mapping layer");
 MODULE_AUTHOR("Juergen Gross ");
 MODULE_LICENSE("GPL");
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index dae0f350c678..a34f4271a2e9 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -219,6 +219,7 @@ static inline void xen_preemptible_hcall_end(void) { }
 void xen_grant_setup_dma_ops(struct device *dev);
 bool xen_is_grant_dma_device(struct device *dev);
 bool xen_virtio_mem_acc(struct virtio_device *dev);
+bool xen_virtio_restricted_mem_acc(struct virtio_device *dev);
 #else
 static inline void xen_grant_setup_dma_ops(struct device *dev)
 {
@@ -234,6 +235,11 @@ static inline bool xen_virtio_mem_acc(struct virtio_device 
*dev)
 {
return false;
 }
+
+static inline bool xen_virtio_restricted_mem_acc(struct virtio_device *dev)
+{
+   return false;
+}
 #endif /* CONFIG_XEN_GRANT_DMA_OPS */
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
2.35.3

[PATCH v2 0/3] xen/virtio: support grant based virtio on x86

2022-10-07 Thread Juergen Gross 
Add basic support for virtio with grants on x86 by defaulting the
backend to be in dom0 in the case the guest kernel was built with
CONFIG_XEN_VIRTIO_FORCE_GRANT.

Juergen Gross (3):
  xen/virtio: restructure xen grant dma setup
  xen/virtio: use dom0 as default backend for
CONFIG_XEN_VIRTIO_FORCE_GRANT
  xen/virtio: enable grant based virtio on x86

 arch/x86/xen/enlighten_hvm.c |  2 +-
 arch/x86/xen/enlighten_pv.c  |  2 +-
 drivers/xen/grant-dma-ops.c  | 83 +---
 include/xen/xen-ops.h|  6 +++
 4 files changed, 65 insertions(+), 28 deletions(-)

-- 
2.35.3

[PATCH v2 1/3] xen/virtio: restructure xen grant dma setup

2022-10-07 Thread Juergen Gross 
In order to prepare supporting other means than device tree for
setting up virtio devices under Xen, restructure the functions
xen_is_grant_dma_device() and xen_grant_setup_dma_ops() a little bit.

Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Tested-by: Oleksandr Tyshchenko  # Arm64 only
Acked-by: Stefano Stabellini 
---
V2:
- rename xen_dt_grant_setup_dma_ops() (Oleksandr Tyshchenko)
---
 drivers/xen/grant-dma-ops.c | 68 +++--
 1 file changed, 43 insertions(+), 25 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 8973fc1e9ccc..646ca913c05c 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -273,22 +273,28 @@ static const struct dma_map_ops xen_grant_dma_ops = {
.dma_supported = xen_grant_dma_supported,
 };
 
-bool xen_is_grant_dma_device(struct device *dev)
+static bool xen_is_dt_grant_dma_device(struct device *dev)
 {
struct device_node *iommu_np;
bool has_iommu;
 
-   /* XXX Handle only DT devices for now */
-   if (!dev->of_node)
-   return false;
-
iommu_np = of_parse_phandle(dev->of_node, "iommus", 0);
-   has_iommu = iommu_np && of_device_is_compatible(iommu_np, 
"xen,grant-dma");
+   has_iommu = iommu_np &&
+   of_device_is_compatible(iommu_np, "xen,grant-dma");
of_node_put(iommu_np);
 
return has_iommu;
 }
 
+bool xen_is_grant_dma_device(struct device *dev)
+{
+   /* XXX Handle only DT devices for now */
+   if (dev->of_node)
+   return xen_is_dt_grant_dma_device(dev);
+
+   return false;
+}
+
 bool xen_virtio_mem_acc(struct virtio_device *dev)
 {
if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT))
@@ -297,45 +303,56 @@ bool xen_virtio_mem_acc(struct virtio_device *dev)
return xen_is_grant_dma_device(dev->dev.parent);
 }
 
-void xen_grant_setup_dma_ops(struct device *dev)
+static int xen_dt_grant_init_backend_domid(struct device *dev,
+  struct xen_grant_dma_data *data)
 {
-   struct xen_grant_dma_data *data;
struct of_phandle_args iommu_spec;
 
-   data = find_xen_grant_dma_data(dev);
-   if (data) {
-   dev_err(dev, "Xen grant DMA data is already created\n");
-   return;
-   }
-
-   /* XXX ACPI device unsupported for now */
-   if (!dev->of_node)
-   goto err;
-
if (of_parse_phandle_with_args(dev->of_node, "iommus", "#iommu-cells",
0, _spec)) {
dev_err(dev, "Cannot parse iommus property\n");
-   goto err;
+   return -ESRCH;
}
 
if (!of_device_is_compatible(iommu_spec.np, "xen,grant-dma") ||
iommu_spec.args_count != 1) {
dev_err(dev, "Incompatible IOMMU node\n");
of_node_put(iommu_spec.np);
-   goto err;
+   return -ESRCH;
}
 
of_node_put(iommu_spec.np);
 
+   /*
+* The endpoint ID here means the ID of the domain where the
+* corresponding backend is running
+*/
+   data->backend_domid = iommu_spec.args[0];
+
+   return 0;
+}
+
+void xen_grant_setup_dma_ops(struct device *dev)
+{
+   struct xen_grant_dma_data *data;
+
+   data = find_xen_grant_dma_data(dev);
+   if (data) {
+   dev_err(dev, "Xen grant DMA data is already created\n");
+   return;
+   }
+
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
goto err;
 
-   /*
-* The endpoint ID here means the ID of the domain where the 
corresponding
-* backend is running
-*/
-   data->backend_domid = iommu_spec.args[0];
+   if (dev->of_node) {
+   if (xen_dt_grant_init_backend_domid(dev, data))
+   goto err;
+   } else {
+   /* XXX ACPI device unsupported for now */
+   goto err;
+   }
 
if (xa_err(xa_store(_grant_dma_devices, (unsigned long)dev, data,
GFP_KERNEL))) {
@@ -348,6 +365,7 @@ void xen_grant_setup_dma_ops(struct device *dev)
return;
 
 err:
+   devm_kfree(dev, data);
dev_err(dev, "Cannot set up Xen grant DMA ops, retain platform DMA 
ops\n");
 }
 
-- 
2.35.3