[ovmf test] 163367: regressions - FAIL
flight 163367 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/163367/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf 0a6b303dcedb7af238ad485d545802befb797b3a baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 33 days Failing since162368 2021-06-04 15:42:59 Z 32 days 92 attempts Testing same since 163340 2021-07-06 15:40:15 Z0 days2 attempts People who touched revisions under test: Abner Chang Agrawal, Sachin Alexandru Elisei Anthony PERARD Ard Biesheuvel Corvin Köhne Daniel Schaefer Daoxiang Li Dov Murik DunTan gaoliming Guo Dong Hao A Wu Jian J Wang Kaaira Gupta Ken Lautner Kenneth Lautner Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Loo Tung Lun Loo, Tung Lun Manickavasakam Karpagavinayagam Maurice Ma Neal Gompa Ni, Ray Patrick Rudolph Pierre Gondois Ray Ni Rebecca Cran Rebecca Cran Sachin Agrawal Sami Mujawar Scottie Kuo Sean Brogan Sean Brogan Sheng Wei Sumana Venur Sunil V L xueshengfeng Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 3335 lines long.)
Ping: [PATCH v4 2/2] docs/designs/launch: Hyperlaunch device tree
On Thu, May 13, 2021 at 8:41 PM Christopher Clark
wrote:
>
> From: "Daniel P. Smith"
>
> Adds a design document for Hyperlaunch device tree structure.
>
> Signed-off-by: Christopher Clark
> Signed-off by: Daniel P. Smith
> ---
> .../designs/launch/hyperlaunch-devicetree.rst | 343 ++
> 1 file changed, 343 insertions(+)
> create mode 100644 docs/designs/launch/hyperlaunch-devicetree.rst
>
> diff --git a/docs/designs/launch/hyperlaunch-devicetree.rst
> b/docs/designs/launch/hyperlaunch-devicetree.rst
> new file mode 100644
> index 00..f97d357407
> --- /dev/null
> +++ b/docs/designs/launch/hyperlaunch-devicetree.rst
> @@ -0,0 +1,343 @@
> +-
> +Xen Hyperlaunch Device Tree Bindings
> +-
> +
> +The Xen Hyperlaunch device tree adopts the dom0less device tree structure and
> +extends it to meet the requirements for the Hyperlaunch capability. The
> primary
> +difference is the introduction of the ``hypervisor`` node that is under the
> +``/chosen`` node. The move to a dedicated node was driven by:
> +
> +1. Reduces the need to walk over nodes that are not of interest, e.g. only
> + nodes of interest should be in ``/chosen/hypervisor``
> +
> +2. Allows for the domain construction information to easily be sanitized by
> + simple removing the ``/chosen/hypervisor`` node.
> +
> +Example Configuration
> +-
> +
> +Below are two example device tree definitions for the hypervisor node. The
> +first is an example of a multiboot-based configuration for x86 and the second
> +is a module-based configuration for Arm.
> +
> +Multiboot x86 Configuration:
> +
> +
> +::
> +
> +hypervisor {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +compatible = “hypervisor,xen”
> +
> +// Configuration container
> +config {
> +compatible = "xen,config";
> +
> +module {
> +compatible = "module,microcode", "multiboot,module";
> +mb-index = <1>;
> +};
> +
> +module {
> +compatible = "module,xsm-policy", "multiboot,module";
> +mb-index = <2>;
> +};
> +};
> +
> +// Boot Domain definition
> +domain {
> +compatible = "xen,domain";
> +
> +domid = <0x7FF5>;
> +
> +// FUNCTION_NONE(0)
> +// FUNCTION_BOOT(1 << 0)
> +// FUNCTION_CRASH (1 << 1)
> +// FUNCTION_CONSOLE (1 << 2)
> +// FUNCTION_XENSTORE(1 << 30)
> +// FUNCTION_LEGACY_DOM0 (1 << 31)
> +functions = <0x0001>;
> +
> +memory = <0x0 0x2>;
> +cpus = <1>;
> +module {
> +compatible = "module,kernel", "multiboot,module";
> +mb-index = <3>;
> +};
> +
> +module {
> +compatible = "module,ramdisk", "multiboot,module";
> +mb-index = <4>;
> +};
> +module {
> +compatible = "module,config", "multiboot,module";
> +mb-index = <5>;
> +};
> +
> +// Classic Dom0 definition
> +domain {
> +compatible = "xen,domain";
> +
> +domid = <0>;
> +
> +// PERMISSION_NONE (0)
> +// PERMISSION_CONTROL (1 << 0)
> +// PERMISSION_HARDWARE (1 << 1)
> +permissions = <3>;
> +
> +// FUNCTION_NONE(0)
> +// FUNCTION_BOOT(1 << 0)
> +// FUNCTION_CRASH (1 << 1)
> +// FUNCTION_CONSOLE (1 << 2)
> +// FUNCTION_XENSTORE(1 << 30)
> +// FUNCTION_LEGACY_DOM0 (1 << 31)
> +functions = <0xC006>;
> +
> +// MODE_PARAVIRTUALIZED (1 << 0) /* PV | PVH/HVM */
> +// MODE_ENABLE_DEVICE_MODEL (1 << 1) /* HVM | PVH */
> +// MODE_LONG(1 << 2) /* 64 BIT | 32 BIT */
> +mode = <5>; /* 64 BIT, PV */
> +
> +// UUID
> +domain-uuid = [B3 FB 98 FB 8F 9F 67 A3];
> +
> +cpus = <1>;
> +memory = <0x0 0x2>;
> +security-id = “dom0_t;
> +
> +module {
> +compatible = "module,kernel", "multiboot,module";
> +mb-index = <6>;
> +bootargs = "console=hvc0";
> +};
> +module {
> +compatible = "module,ramdisk", "multiboot,module";
> +mb-index = <7>;
> +};
> +};
> +
> +The multiboot modules supplied when using the above config would be, in
> order:
> +
> +* (the above config, compiled)
> +* CPU microcode
> +* XSM policy
> +* kernel for boot domain
> +* ramdisk for boot domain
> +*
Ping: [PATCH v4 1/2] docs/designs/launch: Hyperlaunch design document
On Thu, May 13, 2021 at 8:41 PM Christopher Clark wrote: > > From: "Daniel P. Smith" > > Adds a design document for Hyperlaunch, formerly DomB mode of dom0less. > > Signed-off-by: Christopher Clark > Signed-off by: Daniel P. Smith > Reviewed-by: Rich Persaud > > --- > Changes since v3: > * Rename the Landscape table > * Changed Crash Domain to Recovery Domain > * amended text to indicate that this will be new rather than existing Xen > functionality > * including update to the configuration, permission, function table > * Add definitions for “recovery domain” and “crash environment”, describing > the different functionalities > * some design issues deferred > * Added section to explain the motivations for the separation between VM > creation (by the hypervisor) and VM configuration (by the boot domain) > * Adjusted the description of the current process for creating a domain > * Added recommendation for UEFI boot to use GRUB.efi to load via multiboot2 > method. > * Added Document Structure section > * Added section on Communication of Domain Configuration > > docs/designs/launch/hyperlaunch.rst | 1004 +++ > 1 file changed, 1004 insertions(+) > create mode 100644 docs/designs/launch/hyperlaunch.rst > > diff --git a/docs/designs/launch/hyperlaunch.rst > b/docs/designs/launch/hyperlaunch.rst > new file mode 100644 > index 00..30fce8c9c3 > --- /dev/null > +++ b/docs/designs/launch/hyperlaunch.rst > @@ -0,0 +1,1004 @@ > +### > +Hyperlaunch Design Document > +### > + > +.. sectnum:: :depth: 4 > + > +This post is a Request for Comment on the included v4 of a design document > that > +describes Hyperlaunch: a new method of launching the Xen hypervisor, relating > +to dom0less and work from the Hyperlaunch project. We invite discussion of > this > +on this list, at the monthly Xen Community Calls, and at dedicated meetings > on > +this topic in the Xen Working Group which will be announced in advance on the > +Xen Development mailing list. > + > + > +.. contents:: :depth: 3 > + > + > +Introduction > + > + > +This document describes the design and motivation for the funded development > of > +a new, flexible system for launching the Xen hypervisor and virtual machines > +named: "Hyperlaunch". > + > +The design enables seamless transition for existing systems that require a > +dom0, and provides a new general capability to build and launch alternative > +configurations of virtual machines, including support for static partitioning > +and accelerated start of VMs during host boot, while adhering to the > principles > +of least privilege. It incorporates the existing dom0less functionality, > +extended to fold in the new developments from the Hyperlaunch project, with > +support for both x86 and Arm platform architectures, building upon and > +replacing the earlier 'late hardware domain' feature for disaggregation of > +dom0. > + > +Hyperlaunch is designed to be flexible and reusable across multiple use > cases, > +and our aim is to ensure that it is capable, widely exercised, > comprehensively > +tested, and well understood by the Xen community. > + > +Document Structure > +== > + > +This is the primary design document for Hyperlaunch, to provide an overview > of > +the feature. Separate additional documents will cover specific aspects of > +Hyperlaunch in further detail, including: > + > + - The Device Tree specification for Hyperlaunch metadata > + - New Domain Roles for Xen and the Xen Security Modules (XSM) policy > + - Passthrough of PCI devices with Hyperlaunch > + > +Approach > + > + > +Born out of improving support for Dynamic Root of Trust for Measurement > (DRTM), > +the Hyperlaunch project is focused on restructuring the system launch of Xen. > +The Hyperlaunch design provides a security architecture that builds on the > +principles of Least Privilege and Strong Isolation, achieving this through > the > +disaggregation of system functions. It enables this with the introduction of > a > +boot domain that works in conjunction with the hypervisor to provide the > +ability to launch multiple domains as part of host boot while maintaining a > +least privilege implementation. > + > +While the Hyperlaunch project inception was and continues to be driven by a > +focus on security through disaggregation, there are multiple use cases with a > +non-security focus that require or benefit from the ability to launch > multiple > +domains at host boot. This was proven by the need that drove the > implementation > +of the dom0less capability in the Arm branch of Xen. > + > +Hyperlaunch is designed to be flexible and reusable across multiple use > cases, > +and our aim is to ensure that it is capable, widely exercised, > comprehensively > +tested, and provides a robust foundation for current and emerging system > launch > +requirements of the Xen community. > + > +
Ping: [PATCH v4 0/2] Introducing Hyperlaunch capability design (formerly: DomB mode of dom0less)
On Fri, May 14, 2021 at 7:19 AM Daniel P. Smith wrote: > > On 5/13/21 11:40 PM, Christopher Clark wrote: > > We are submitting for inclusion in the Xen documentation: > > > > - the Hyperlaunch design document, and > > - the Hyperlaunch device tree design document > > > > to describe a new method for launching the Xen hypervisor. We would like to have these design documents merged, please. We have responded to all of the feedback provided in previous rounds and no further comments have been received on these since they were posted in May. thanks, Christopher > > > > The Hyperlaunch feature builds upon prior dom0less work, > > to bring a flexible and security-minded means to launch a > > variety of VM configurations as part of the startup of Xen. > > > > Signed-off-by: Christopher Clark > > Signed-off by: Daniel P. Smith > > > > > > Daniel P. Smith (2): > > docs/designs/launch: hyperlaunch design document > > docs/designs/launch: hyperlaunch device tree > > > > .../designs/launch/hyperlaunch-devicetree.rst | 343 ++ > > docs/designs/launch/hyperlaunch.rst | 1004 + > > 2 files changed, 1347 insertions(+) > > create mode 100644 docs/designs/launch/hyperlaunch-devicetree.rst > > create mode 100644 docs/designs/launch/hyperlaunch.rst > > > > All, > > Please find a rendered PDF copy of each document attached for ease of > reading. > > V/r, > Daniel P. Smith > Apertus Solutions, LLC
[xen-unstable test] 163362: tolerable FAIL - PUSHED
flight 163362 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/163362/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 163323 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 163323 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 163323 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 163323 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 163323 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 163323 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 163323 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 163323 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 163323 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 163323 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 163323 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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 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-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-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-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass version targeted for testing: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a baseline version: xen 44e8904ebfbc57ba0950c40b9d3a28507b553e4e Last test of basis 163323 2021-07-06 04:40:42 Z1 days Testing same since 163362 2021-07-06 20:06:44 Z0 days1 attempts People who touched revisions under test: Julien Grall Oleksandr Tyshchenko Sergiy Kibrik jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf
[xen-unstable-smoke test] 163381: regressions - trouble: blocked/fail
flight 163381 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163381/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days 12 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Acked-by: Russell King (Oracle) (For ARM, Amba > and related parts) > Acked-by: Mark Brown > Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) > Acked-by: Pali Rohár > Acked-by: Mauro Carvalho Chehab (for drivers/media) > Acked-by: Hans de Goede (For drivers/platform) > Acked-by: Alexandre Belloni > Acked-By: Vinod Koul > Acked-by: Juergen Gross (For Xen) > Acked-by: Lee Jones (For drivers/mfd) > Acked-by: Johannes Thumshirn (For drivers/mcb) > Acked-by: Johan Hovold > Acked-by: Srinivas Kandagatla (For > drivers/slimbus) > Acked-by: Kirti Wankhede (For drivers/vfio) > Acked-by: Maximilian Luz > Acked-by: Heikki Krogerus (For ulpi and > typec) > Acked-by: Samuel Iglesias Gonsálvez (For ipack) > Reviewed-by: Tom Rix (For fpga) > Acked-by: Geoff Levand (For ps3) > Signed-off-by: Uwe Kleine-König > --- > drivers/base/isa.c| 4 +--- Acked-by: William Breathitt Gray signature.asc Description: PGP signature
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, Jul 6, 2021 at 8:51 AM Uwe Kleine-König wrote: > > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- For CXL, DAX, and NVDIMM Acked-by: Dan Williams
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, 2021-07-06 at 17:48 +0200, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because > there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by > drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't > anticipate > wrong expectations for driver authors. > > Acked-by: Russell King (Oracle) (For > ARM, Amba and related parts) > Acked-by: Mark Brown > Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) > Acked-by: Pali Rohár > Acked-by: Mauro Carvalho Chehab (for > drivers/media) > Acked-by: Hans de Goede (For drivers/platform) > Acked-by: Alexandre Belloni > Acked-By: Vinod Koul > Acked-by: Juergen Gross (For Xen) > Acked-by: Lee Jones (For drivers/mfd) > Acked-by: Johannes Thumshirn (For drivers/mcb) > Acked-by: Johan Hovold > Acked-by: Srinivas Kandagatla (For > drivers/slimbus) > Acked-by: Kirti Wankhede (For drivers/vfio) > Acked-by: Maximilian Luz > Acked-by: Heikki Krogerus (For ulpi > and typec) > Acked-by: Samuel Iglesias Gonsálvez (For > ipack) > Reviewed-by: Tom Rix (For fpga) > Acked-by: Geoff Levand (For ps3) > Signed-off-by: Uwe Kleine-König For drivers/hid/intel-ish-hid Acked-by: Srinivas Pandruvada > --- > > arch/arm/common/locomo.c | 3 +-- > arch/arm/common/sa.c | 4 +--- > arch/arm/mach-rpc/ecard.c | 4 +--- > arch/mips/sgi-ip22/ip22-gio.c | 3 +-- > arch/parisc/kernel/drivers.c | 5 ++--- > arch/powerpc/platforms/ps3/system-bus.c | 3 +-- > arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- > arch/powerpc/platforms/pseries/vio.c | 3 +-- > drivers/acpi/bus.c | 3 +-- > drivers/amba/bus.c | 4 +--- > drivers/base/auxiliary.c | 4 +--- > drivers/base/isa.c | 4 +--- > drivers/base/platform.c | 4 +--- > drivers/bcma/main.c | 6 ++ > drivers/bus/sunxi-rsb.c | 4 +--- > drivers/cxl/core.c | 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/dma/idxd/sysfs.c | 4 +--- > drivers/firewire/core-device.c | 4 +--- > drivers/firmware/arm_scmi/bus.c | 4 +--- > drivers/firmware/google/coreboot_table.c | 4 +--- > drivers/fpga/dfl.c | 4 +--- > drivers/hid/hid-core.c | 4 +--- > drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- > drivers/hv/vmbus_drv.c | 5 + > drivers/hwtracing/intel_th/core.c | 4 +--- > drivers/i2c/i2c-core-base.c | 5 + > drivers/i3c/master.c | 4 +--- > drivers/input/gameport/gameport.c | 3 +-- > drivers/input/serio/serio.c | 3 +-- > drivers/ipack/ipack.c | 4 +--- > drivers/macintosh/macio_asic.c | 4 +--- > drivers/mcb/mcb-core.c | 4 +--- > drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- > drivers/memstick/core/memstick.c | 3 +-- > drivers/mfd/mcp-core.c | 3 +-- > drivers/misc/mei/bus.c | 4 +--- > drivers/misc/tifm_core.c | 3 +-- > drivers/mmc/core/bus.c | 4 +--- > drivers/mmc/core/sdio_bus.c | 4 +--- > drivers/net/netdevsim/bus.c | 3 +-- > drivers/ntb/core.c | 4 +--- > drivers/ntb/ntb_transport.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- > drivers/pci/endpoint/pci-epf-core.c | 4 +--- > drivers/pci/pci-driver.c | 3 +-- > drivers/pcmcia/ds.c | 4 +--- > drivers/platform/surface/aggregator/bus.c | 4 +--- > drivers/platform/x86/wmi.c | 4 +--- > drivers/pnp/driver.c | 3 +-- > drivers/rapidio/rio-driver.c | 4 +--- > drivers/rpmsg/rpmsg_core.c | 4 +--- > drivers/s390/cio/ccwgroup.c | 4 +--- > drivers/s390/cio/css.c | 4 +--- > drivers/s390/cio/device.c | 4 +--- > drivers/s390/cio/scm.c | 4 +--- > drivers/s390/crypto/ap_bus.c | 4 +--- > drivers/scsi/scsi_debug.c | 3 +-- > drivers/siox/siox-core.c | 4 +--- > drivers/slimbus/core.c | 4 +--- > drivers/soc/qcom/apr.c | 4 +--- > drivers/spi/spi.c | 4 +--- > drivers/spmi/spmi.c | 3 +-- > drivers/ssb/main.c
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their remove callback.
> Additionally some resource leaks were fixed that were caused by drivers
> returning an error code in the expectation that the driver won't go
> away.
>
> With struct bus_type::remove returning void it's prevented that newly
> implemented buses return an ignored error code and so don't anticipate
> wrong expectations for driver authors.
>
Thanks for doing this!
Acked-by: Bjorn Andersson (rpmsg and apr)
[..]
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index c1404d3dae2c..7f6fac618ab2 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -530,7 +530,7 @@ static int rpmsg_dev_probe(struct device *dev)
> return err;
> }
>
> -static int rpmsg_dev_remove(struct device *dev)
> +static void rpmsg_dev_remove(struct device *dev)
> {
> struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
> @@ -546,8 +546,6 @@ static int rpmsg_dev_remove(struct device *dev)
>
> if (rpdev->ept)
> rpmsg_destroy_ept(rpdev->ept);
> -
> - return err;
This leaves err assigned but never used, but I don't mind following up
with a patch cleaning that up after this has landed.
> }
>
> static struct bus_type rpmsg_bus = {
Regards,
Bjorn
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue 06 Jul 13:43 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> > On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > > index c1404d3dae2c..7f6fac618ab2 100644
> > > --- a/drivers/rpmsg/rpmsg_core.c
> > > +++ b/drivers/rpmsg/rpmsg_core.c
> > > @@ -530,7 +530,7 @@ static int rpmsg_dev_probe(struct device *dev)
> > > return err;
> > > }
> > >
> > > -static int rpmsg_dev_remove(struct device *dev)
> > > +static void rpmsg_dev_remove(struct device *dev)
> > > {
> > > struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> > > struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
> > > @@ -546,8 +546,6 @@ static int rpmsg_dev_remove(struct device *dev)
> > >
> > > if (rpdev->ept)
> > > rpmsg_destroy_ept(rpdev->ept);
> > > -
> > > - return err;
> >
> > This leaves err assigned but never used, but I don't mind following up
> > with a patch cleaning that up after this has landed.
>
> Ah, good catch. If I send out a v3 I will fold the following into this
> patch:
>
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index 7f6fac618ab2..9151836190ce 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -534,10 +534,9 @@ static void rpmsg_dev_remove(struct device *dev)
> {
> struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
> - int err = 0;
>
> if (rpdev->ops->announce_destroy)
> - err = rpdev->ops->announce_destroy(rpdev);
> + rpdev->ops->announce_destroy(rpdev);
>
> if (rpdrv->remove)
> rpdrv->remove(rpdev);
>
Sounds good, feel free to keep my ack on this.
> Maybe .announce_destroy() should then be changed to return void, too?
> Something like:
>
Yes, I saw this opportunity as well. But that will fan out further, so
let's postpone that until your series has landed and we can follow up
with such changes through the remoteproc tree.
> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
> index a76c344253bf..d5204756714c 100644
> --- a/drivers/rpmsg/rpmsg_internal.h
> +++ b/drivers/rpmsg/rpmsg_internal.h
> @@ -40,7 +40,7 @@ struct rpmsg_device_ops {
> struct rpmsg_channel_info chinfo);
>
> int (*announce_create)(struct rpmsg_device *ept);
> - int (*announce_destroy)(struct rpmsg_device *ept);
> + void (*announce_destroy)(struct rpmsg_device *ept);
> };
>
> /**
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 8e49a3bacfc7..4e05994634f8 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -340,7 +340,7 @@ static int virtio_rpmsg_announce_create(struct
> rpmsg_device *rpdev)
> return err;
> }
>
> -static int virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
> +static void virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
> {
> struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
> struct virtproc_info *vrp = vch->vrp;
> @@ -360,8 +360,6 @@ static int virtio_rpmsg_announce_destroy(struct
> rpmsg_device *rpdev)
> if (err)
> dev_err(dev, "failed to announce service %d\n", err);
> }
> -
> - return err;
> }
>
> static const struct rpmsg_device_ops virtio_rpmsg_ops = {
>
> though it's not obvious for me that the last hunk is sensible. (OTOH the
> return code is ignored anyhow as rpmsg_dev_remove() is the only caller.
>
I need to backtrack a little bit more to figure out why we ended up with
this...
Thanks,
Bjorn
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, Jul 6, 2021 at 5:53 PM Uwe Kleine-König wrote: > > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Acked-by: Russell King (Oracle) (For ARM, Amba > and related parts) > Acked-by: Mark Brown > Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) > Acked-by: Pali Rohár > Acked-by: Mauro Carvalho Chehab (for drivers/media) > Acked-by: Hans de Goede (For drivers/platform) > Acked-by: Alexandre Belloni > Acked-By: Vinod Koul > Acked-by: Juergen Gross (For Xen) > Acked-by: Lee Jones (For drivers/mfd) > Acked-by: Johannes Thumshirn (For drivers/mcb) > Acked-by: Johan Hovold > Acked-by: Srinivas Kandagatla (For > drivers/slimbus) > Acked-by: Kirti Wankhede (For drivers/vfio) > Acked-by: Maximilian Luz > Acked-by: Heikki Krogerus (For ulpi and > typec) > Acked-by: Samuel Iglesias Gonsálvez (For ipack) > Reviewed-by: Tom Rix (For fpga) > Acked-by: Geoff Levand (For ps3) > Signed-off-by: Uwe Kleine-König For the ACPI part: Acked-by: Rafael J. Wysocki > --- > > arch/arm/common/locomo.c | 3 +-- > arch/arm/common/sa.c | 4 +--- > arch/arm/mach-rpc/ecard.c | 4 +--- > arch/mips/sgi-ip22/ip22-gio.c | 3 +-- > arch/parisc/kernel/drivers.c | 5 ++--- > arch/powerpc/platforms/ps3/system-bus.c | 3 +-- > arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- > arch/powerpc/platforms/pseries/vio.c | 3 +-- > drivers/acpi/bus.c| 3 +-- > drivers/amba/bus.c| 4 +--- > drivers/base/auxiliary.c | 4 +--- > drivers/base/isa.c| 4 +--- > drivers/base/platform.c | 4 +--- > drivers/bcma/main.c | 6 ++ > drivers/bus/sunxi-rsb.c | 4 +--- > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/dma/idxd/sysfs.c | 4 +--- > drivers/firewire/core-device.c| 4 +--- > drivers/firmware/arm_scmi/bus.c | 4 +--- > drivers/firmware/google/coreboot_table.c | 4 +--- > drivers/fpga/dfl.c| 4 +--- > drivers/hid/hid-core.c| 4 +--- > drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- > drivers/hv/vmbus_drv.c| 5 + > drivers/hwtracing/intel_th/core.c | 4 +--- > drivers/i2c/i2c-core-base.c | 5 + > drivers/i3c/master.c | 4 +--- > drivers/input/gameport/gameport.c | 3 +-- > drivers/input/serio/serio.c | 3 +-- > drivers/ipack/ipack.c | 4 +--- > drivers/macintosh/macio_asic.c| 4 +--- > drivers/mcb/mcb-core.c| 4 +--- > drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- > drivers/memstick/core/memstick.c | 3 +-- > drivers/mfd/mcp-core.c| 3 +-- > drivers/misc/mei/bus.c| 4 +--- > drivers/misc/tifm_core.c | 3 +-- > drivers/mmc/core/bus.c| 4 +--- > drivers/mmc/core/sdio_bus.c | 4 +--- > drivers/net/netdevsim/bus.c | 3 +-- > drivers/ntb/core.c| 4 +--- > drivers/ntb/ntb_transport.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- > drivers/pci/endpoint/pci-epf-core.c | 4 +--- > drivers/pci/pci-driver.c | 3 +-- > drivers/pcmcia/ds.c | 4 +--- > drivers/platform/surface/aggregator/bus.c | 4 +--- > drivers/platform/x86/wmi.c| 4 +--- > drivers/pnp/driver.c | 3 +-- > drivers/rapidio/rio-driver.c | 4 +--- > drivers/rpmsg/rpmsg_core.c| 4 +--- > drivers/s390/cio/ccwgroup.c | 4 +--- > drivers/s390/cio/css.c| 4 +--- > drivers/s390/cio/device.c | 4 +--- > drivers/s390/cio/scm.c| 4 +--- > drivers/s390/crypto/ap_bus.c | 4 +--- > drivers/scsi/scsi_debug.c | 3 +-- > drivers/siox/siox-core.c | 4 +--- > drivers/slimbus/core.c| 4 +--- > drivers/soc/qcom/apr.c| 4 +--- > drivers/spi/spi.c | 4 +--- > drivers/spmi/spmi.c | 3 +-- > drivers/ssb/main.c| 4
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, Jul 06 2021, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Acked-by: Russell King (Oracle) (For ARM, Amba > and related parts) > Acked-by: Mark Brown > Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) > Acked-by: Pali Rohár > Acked-by: Mauro Carvalho Chehab (for drivers/media) > Acked-by: Hans de Goede (For drivers/platform) > Acked-by: Alexandre Belloni > Acked-By: Vinod Koul > Acked-by: Juergen Gross (For Xen) > Acked-by: Lee Jones (For drivers/mfd) > Acked-by: Johannes Thumshirn (For drivers/mcb) > Acked-by: Johan Hovold > Acked-by: Srinivas Kandagatla (For > drivers/slimbus) > Acked-by: Kirti Wankhede (For drivers/vfio) > Acked-by: Maximilian Luz > Acked-by: Heikki Krogerus (For ulpi and > typec) > Acked-by: Samuel Iglesias Gonsálvez (For ipack) > Reviewed-by: Tom Rix (For fpga) > Acked-by: Geoff Levand (For ps3) > Signed-off-by: Uwe Kleine-König > --- > > drivers/s390/cio/ccwgroup.c | 4 +--- > drivers/s390/cio/css.c| 4 +--- > drivers/s390/cio/device.c | 4 +--- > drivers/s390/cio/scm.c| 4 +--- > drivers/s390/crypto/ap_bus.c | 4 +--- > drivers/vfio/mdev/mdev_driver.c | 4 +--- For drivers/s390 and drivers/vfio: Reviewed-by: Cornelia Huck
[PATCH v2 0/4] bus: Make remove callback return void
Hello, compared to (implicit) v1 that I sent earlier today (https://lore.kernel.org/r/20210706095037.1425211-1-u.kleine-koe...@pengutronix.de) the following is changed: - Add three more patches preparing some s390 specific busses and adapt them in the last patch. Thanks to Cornelia Huck for pointing this out. - Add various Acks to the last patch I now tested allmodconfig on arm, powerpc, s390 and amd64. As before this depends on "PCI: endpoint: Make struct pci_epf_driver::remove return void" that is not yet applied, see https://lore.kernel.org/r/20210223090757.57604-1-u.kleine-koe...@pengutronix.de. Best regards Uwe Uwe Kleine-König (4): s390/cio: Make struct css_driver::remove return void s390/ccwgroup: Drop if with an always false condition s390/scm: Make struct scm_driver::remove return void bus: Make remove callback return void arch/arm/common/locomo.c | 3 +-- arch/arm/common/sa.c | 4 +--- arch/arm/mach-rpc/ecard.c | 4 +--- arch/mips/sgi-ip22/ip22-gio.c | 3 +-- arch/parisc/kernel/drivers.c | 5 ++--- arch/powerpc/platforms/ps3/system-bus.c | 3 +-- arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- arch/powerpc/platforms/pseries/vio.c | 3 +-- arch/s390/include/asm/eadm.h | 2 +- drivers/acpi/bus.c| 3 +-- drivers/amba/bus.c| 4 +--- drivers/base/auxiliary.c | 4 +--- drivers/base/isa.c| 4 +--- drivers/base/platform.c | 4 +--- drivers/bcma/main.c | 6 ++ drivers/bus/sunxi-rsb.c | 4 +--- drivers/cxl/core.c| 3 +-- drivers/dax/bus.c | 4 +--- drivers/dma/idxd/sysfs.c | 4 +--- drivers/firewire/core-device.c| 4 +--- drivers/firmware/arm_scmi/bus.c | 4 +--- drivers/firmware/google/coreboot_table.c | 4 +--- drivers/fpga/dfl.c| 4 +--- drivers/hid/hid-core.c| 4 +--- drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- drivers/hv/vmbus_drv.c| 5 + drivers/hwtracing/intel_th/core.c | 4 +--- drivers/i2c/i2c-core-base.c | 5 + drivers/i3c/master.c | 4 +--- drivers/input/gameport/gameport.c | 3 +-- drivers/input/serio/serio.c | 3 +-- drivers/ipack/ipack.c | 4 +--- drivers/macintosh/macio_asic.c| 4 +--- drivers/mcb/mcb-core.c| 4 +--- drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- drivers/memstick/core/memstick.c | 3 +-- drivers/mfd/mcp-core.c| 3 +-- drivers/misc/mei/bus.c| 4 +--- drivers/misc/tifm_core.c | 3 +-- drivers/mmc/core/bus.c| 4 +--- drivers/mmc/core/sdio_bus.c | 4 +--- drivers/net/netdevsim/bus.c | 3 +-- drivers/ntb/core.c| 4 +--- drivers/ntb/ntb_transport.c | 4 +--- drivers/nvdimm/bus.c | 3 +-- drivers/pci/endpoint/pci-epf-core.c | 4 +--- drivers/pci/pci-driver.c | 3 +-- drivers/pcmcia/ds.c | 4 +--- drivers/platform/surface/aggregator/bus.c | 4 +--- drivers/platform/x86/wmi.c| 4 +--- drivers/pnp/driver.c | 3 +-- drivers/rapidio/rio-driver.c | 4 +--- drivers/rpmsg/rpmsg_core.c| 4 +--- drivers/s390/block/scm_drv.c | 4 +--- drivers/s390/cio/ccwgroup.c | 6 +- drivers/s390/cio/chsc_sch.c | 3 +-- drivers/s390/cio/css.c| 7 +++ drivers/s390/cio/css.h| 2 +- drivers/s390/cio/device.c | 9 +++-- drivers/s390/cio/eadm_sch.c | 4 +--- drivers/s390/cio/scm.c| 5 +++-- drivers/s390/cio/vfio_ccw_drv.c | 3 +-- drivers/s390/crypto/ap_bus.c | 4 +--- drivers/scsi/scsi_debug.c | 3 +-- drivers/siox/siox-core.c | 4 +--- drivers/slimbus/core.c| 4 +--- drivers/soc/qcom/apr.c| 4 +--- drivers/spi/spi.c | 4 +--- drivers/spmi/spmi.c | 3 +-- drivers/ssb/main.c| 4 +--- drivers/staging/fieldbus/anybuss/host.c | 4 +--- drivers/staging/greybus/gbphy.c | 4 +--- drivers/target/loopback/tcm_loop.c| 5 ++--- drivers/thunderbolt/domain.c | 4 +--- drivers/tty/serdev/core.c | 4 +--- drivers/usb/common/ulpi.c | 4 +--- drivers/usb/serial/bus.c | 4 +--- drivers/usb/typec/bus.c | 4 +--- drivers/vdpa/vdpa.c | 4 +---
Re: [PATCH v2 4/4] bus: Make remove callback return void
Hello, v1 was acked by some more after I stopped looking in my mailbox while preparing v2: On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Acked-by: Russell King (Oracle) (For ARM, Amba > and related parts) > Acked-by: Mark Brown > Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) > Acked-by: Pali Rohár > Acked-by: Mauro Carvalho Chehab (for drivers/media) > Acked-by: Hans de Goede (For drivers/platform) > Acked-by: Alexandre Belloni > Acked-By: Vinod Koul > Acked-by: Juergen Gross (For Xen) > Acked-by: Lee Jones (For drivers/mfd) > Acked-by: Johannes Thumshirn (For drivers/mcb) > Acked-by: Johan Hovold > Acked-by: Srinivas Kandagatla (For > drivers/slimbus) > Acked-by: Kirti Wankhede (For drivers/vfio) > Acked-by: Maximilian Luz > Acked-by: Heikki Krogerus (For ulpi and > typec) > Acked-by: Samuel Iglesias Gonsálvez (For ipack) > Reviewed-by: Tom Rix (For fpga) > Acked-by: Geoff Levand (For ps3) Acked-by: Yehezkel Bernat (For thunderbolt) Reviewed-by: Mathieu Poirier Acked-by: Alexander Shishkin (For intel_th) Acked-by: Dominik Brodowski (For pcmcia) > Signed-off-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[PATCH v2 4/4] bus: Make remove callback return void
The driver core ignores the return value of this callback because there is only little it can do when a device disappears. This is the final bit of a long lasting cleanup quest where several buses were converted to also return void from their remove callback. Additionally some resource leaks were fixed that were caused by drivers returning an error code in the expectation that the driver won't go away. With struct bus_type::remove returning void it's prevented that newly implemented buses return an ignored error code and so don't anticipate wrong expectations for driver authors. Acked-by: Russell King (Oracle) (For ARM, Amba and related parts) Acked-by: Mark Brown Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) Acked-by: Pali Rohár Acked-by: Mauro Carvalho Chehab (for drivers/media) Acked-by: Hans de Goede (For drivers/platform) Acked-by: Alexandre Belloni Acked-By: Vinod Koul Acked-by: Juergen Gross (For Xen) Acked-by: Lee Jones (For drivers/mfd) Acked-by: Johannes Thumshirn (For drivers/mcb) Acked-by: Johan Hovold Acked-by: Srinivas Kandagatla (For drivers/slimbus) Acked-by: Kirti Wankhede (For drivers/vfio) Acked-by: Maximilian Luz Acked-by: Heikki Krogerus (For ulpi and typec) Acked-by: Samuel Iglesias Gonsálvez (For ipack) Reviewed-by: Tom Rix (For fpga) Acked-by: Geoff Levand (For ps3) Signed-off-by: Uwe Kleine-König --- arch/arm/common/locomo.c | 3 +-- arch/arm/common/sa.c | 4 +--- arch/arm/mach-rpc/ecard.c | 4 +--- arch/mips/sgi-ip22/ip22-gio.c | 3 +-- arch/parisc/kernel/drivers.c | 5 ++--- arch/powerpc/platforms/ps3/system-bus.c | 3 +-- arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- arch/powerpc/platforms/pseries/vio.c | 3 +-- drivers/acpi/bus.c| 3 +-- drivers/amba/bus.c| 4 +--- drivers/base/auxiliary.c | 4 +--- drivers/base/isa.c| 4 +--- drivers/base/platform.c | 4 +--- drivers/bcma/main.c | 6 ++ drivers/bus/sunxi-rsb.c | 4 +--- drivers/cxl/core.c| 3 +-- drivers/dax/bus.c | 4 +--- drivers/dma/idxd/sysfs.c | 4 +--- drivers/firewire/core-device.c| 4 +--- drivers/firmware/arm_scmi/bus.c | 4 +--- drivers/firmware/google/coreboot_table.c | 4 +--- drivers/fpga/dfl.c| 4 +--- drivers/hid/hid-core.c| 4 +--- drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- drivers/hv/vmbus_drv.c| 5 + drivers/hwtracing/intel_th/core.c | 4 +--- drivers/i2c/i2c-core-base.c | 5 + drivers/i3c/master.c | 4 +--- drivers/input/gameport/gameport.c | 3 +-- drivers/input/serio/serio.c | 3 +-- drivers/ipack/ipack.c | 4 +--- drivers/macintosh/macio_asic.c| 4 +--- drivers/mcb/mcb-core.c| 4 +--- drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- drivers/memstick/core/memstick.c | 3 +-- drivers/mfd/mcp-core.c| 3 +-- drivers/misc/mei/bus.c| 4 +--- drivers/misc/tifm_core.c | 3 +-- drivers/mmc/core/bus.c| 4 +--- drivers/mmc/core/sdio_bus.c | 4 +--- drivers/net/netdevsim/bus.c | 3 +-- drivers/ntb/core.c| 4 +--- drivers/ntb/ntb_transport.c | 4 +--- drivers/nvdimm/bus.c | 3 +-- drivers/pci/endpoint/pci-epf-core.c | 4 +--- drivers/pci/pci-driver.c | 3 +-- drivers/pcmcia/ds.c | 4 +--- drivers/platform/surface/aggregator/bus.c | 4 +--- drivers/platform/x86/wmi.c| 4 +--- drivers/pnp/driver.c | 3 +-- drivers/rapidio/rio-driver.c | 4 +--- drivers/rpmsg/rpmsg_core.c| 4 +--- drivers/s390/cio/ccwgroup.c | 4 +--- drivers/s390/cio/css.c| 4 +--- drivers/s390/cio/device.c | 4 +--- drivers/s390/cio/scm.c| 4 +--- drivers/s390/crypto/ap_bus.c | 4 +--- drivers/scsi/scsi_debug.c | 3 +-- drivers/siox/siox-core.c | 4 +--- drivers/slimbus/core.c| 4 +--- drivers/soc/qcom/apr.c| 4 +--- drivers/spi/spi.c | 4 +--- drivers/spmi/spmi.c | 3 +-- drivers/ssb/main.c| 4 +--- drivers/staging/fieldbus/anybuss/host.c | 4 +--- drivers/staging/greybus/gbphy.c | 4 +--- drivers/target/loopback/tcm_loop.c| 5 ++--- drivers/thunderbolt/domain.c | 4 +--- drivers/tty/serdev/core.c | 4 +--- drivers/usb/common/ulpi.c
Re: [PATCH] bus: Make remove callback return void
Uwe Kleine-König writes: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Signed-off-by: Uwe Kleine-König FWIW, the intel_th bit is Acked-by: Alexander Shishkin
Re: [PATCH] bus: Make remove callback return void
On Tue, 6 Jul 2021 at 03:56, Uwe Kleine-König wrote: > > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Signed-off-by: Uwe Kleine-König > --- > Hello, > > this patch depends on "PCI: endpoint: Make struct pci_epf_driver::remove > return void" that is not yet applied, see > https://lore.kernel.org/r/20210223090757.57604-1-u.kleine-koe...@pengutronix.de. > > I tested it using allmodconfig on amd64 and arm, but I wouldn't be > surprised if I still missed to convert a driver. So it would be great to > get this into next early after the merge window closes. > > I send this mail to all people that get_maintainer.pl emits for this > patch. I wonder how many recipents will refuse this mail because of the > long Cc: list :-) > > Best regards > Uwe > > arch/arm/common/locomo.c | 3 +-- > arch/arm/common/sa.c | 4 +--- > arch/arm/mach-rpc/ecard.c | 4 +--- > arch/mips/sgi-ip22/ip22-gio.c | 3 +-- > arch/parisc/kernel/drivers.c | 5 ++--- > arch/powerpc/platforms/ps3/system-bus.c | 3 +-- > arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- > arch/powerpc/platforms/pseries/vio.c | 3 +-- > drivers/acpi/bus.c| 3 +-- > drivers/amba/bus.c| 4 +--- > drivers/base/auxiliary.c | 4 +--- > drivers/base/isa.c| 4 +--- > drivers/base/platform.c | 4 +--- > drivers/bcma/main.c | 6 ++ > drivers/bus/sunxi-rsb.c | 4 +--- > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/dma/idxd/sysfs.c | 4 +--- > drivers/firewire/core-device.c| 4 +--- > drivers/firmware/arm_scmi/bus.c | 4 +--- > drivers/firmware/google/coreboot_table.c | 4 +--- > drivers/fpga/dfl.c| 4 +--- > drivers/hid/hid-core.c| 4 +--- > drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- > drivers/hv/vmbus_drv.c| 5 + > drivers/hwtracing/intel_th/core.c | 4 +--- > drivers/i2c/i2c-core-base.c | 5 + > drivers/i3c/master.c | 4 +--- > drivers/input/gameport/gameport.c | 3 +-- > drivers/input/serio/serio.c | 3 +-- > drivers/ipack/ipack.c | 4 +--- > drivers/macintosh/macio_asic.c| 4 +--- > drivers/mcb/mcb-core.c| 4 +--- > drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- > drivers/memstick/core/memstick.c | 3 +-- > drivers/mfd/mcp-core.c| 3 +-- > drivers/misc/mei/bus.c| 4 +--- > drivers/misc/tifm_core.c | 3 +-- > drivers/mmc/core/bus.c| 4 +--- > drivers/mmc/core/sdio_bus.c | 4 +--- > drivers/net/netdevsim/bus.c | 3 +-- > drivers/ntb/core.c| 4 +--- > drivers/ntb/ntb_transport.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- > drivers/pci/endpoint/pci-epf-core.c | 4 +--- > drivers/pci/pci-driver.c | 3 +-- > drivers/pcmcia/ds.c | 4 +--- > drivers/platform/surface/aggregator/bus.c | 4 +--- > drivers/platform/x86/wmi.c| 4 +--- > drivers/pnp/driver.c | 3 +-- > drivers/rapidio/rio-driver.c | 4 +--- > drivers/rpmsg/rpmsg_core.c| 4 +--- Reviewed-by: Mathieu Poirier
Re: [PATCH] bus: Make remove callback return void
On Tue, Jul 6, 2021 at 12:50 PM Uwe Kleine-König wrote: > > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Signed-off-by: Uwe Kleine-König > --- > > drivers/thunderbolt/domain.c | 4 +--- For Thunderbolt: Acked-by: Yehezkel Bernat
[xen-unstable-smoke test] 163379: regressions - trouble: blocked/fail
flight 163379 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163379/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days 11 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
[xen-unstable-smoke test] 163375: regressions - trouble: blocked/fail
flight 163375 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163375/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days 10 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
Re: A possible pointer_overflow in xen-4.13
After patching it, this works fine and UBSAN dose not have any error report about it. --Original-- From: "Andrew Cooper";
RE: [PATCH 07/16] x86/P2M: p2m_{alloc,free}_ptp() and p2m_alloc_table() are HVM-only
> From: Jan Beulich
> Sent: Tuesday, July 6, 2021 12:09 AM
>
> This also includes the two p2m related fields.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -94,7 +94,9 @@ static int p2m_initialise(struct domain
> int ret = 0;
>
> mm_rwlock_init(>lock);
> +#ifdef CONFIG_HVM
> INIT_PAGE_LIST_HEAD(>pages);
> +#endif
>
> p2m->domain = d;
> p2m->default_access = p2m_access_rwx;
> @@ -628,6 +630,7 @@ struct page_info *p2m_get_page_from_gfn(
> }
>
> #ifdef CONFIG_HVM
> +
> /* Returns: 0 for success, -errno for failure */
> int p2m_set_entry(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
>unsigned int page_order, p2m_type_t p2mt, p2m_access_t
> p2ma)
> @@ -667,7 +670,6 @@ int p2m_set_entry(struct p2m_domain *p2m
>
> return rc;
> }
> -#endif
>
> mfn_t p2m_alloc_ptp(struct p2m_domain *p2m, unsigned int level)
> {
> @@ -746,6 +748,8 @@ int p2m_alloc_table(struct p2m_domain *p
> return 0;
> }
>
> +#endif /* CONFIG_HVM */
> +
> /*
> * hvm fixme: when adding support for pvh non-hardware domains, this
> path must
> * cleanup any foreign p2m types (release refcnts on them).
> @@ -754,7 +758,9 @@ void p2m_teardown(struct p2m_domain *p2m
> /* Return all the p2m pages to Xen.
> * We know we don't have any extra mappings to these pages */
> {
> +#ifdef CONFIG_HVM
> struct page_info *pg;
> +#endif
> struct domain *d;
>
> if (p2m == NULL)
> @@ -763,11 +769,16 @@ void p2m_teardown(struct p2m_domain *p2m
> d = p2m->domain;
>
> p2m_lock(p2m);
> +
> ASSERT(atomic_read(>shr_pages) == 0);
> +
> +#ifdef CONFIG_HVM
> p2m->phys_table = pagetable_null();
>
> while ( (pg = page_list_remove_head(>pages)) )
> d->arch.paging.free_page(d, pg);
> +#endif
> +
> p2m_unlock(p2m);
> }
>
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2700,8 +2700,10 @@ int shadow_enable(struct domain *d, u32
> out_locked:
> paging_unlock(d);
> out_unlocked:
> +#ifdef CONFIG_HVM
> if ( rv != 0 && !pagetable_is_null(p2m_get_pagetable(p2m)) )
> p2m_teardown(p2m);
> +#endif
> if ( rv != 0 && pg != NULL )
> {
> pg->count_info &= ~PGC_count_mask;
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -339,12 +339,14 @@ static uint64_t domain_pgd_maddr(struct
>
> ASSERT(spin_is_locked(>arch.mapping_lock));
>
> +#ifdef CONFIG_HVM
> if ( iommu_use_hap_pt(d) )
> {
> pagetable_t pgt = p2m_get_pagetable(p2m_get_hostp2m(d));
>
> return pagetable_get_paddr(pgt);
> }
> +#endif
>
> if ( !hd->arch.vtd.pgd_maddr )
> {
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -202,9 +202,6 @@ struct p2m_domain {
> /* Lock that protects updates to the p2m */
> mm_rwlock_t lock;
>
> -/* Shadow translated domain: p2m mapping */
> -pagetable_tphys_table;
> -
> /*
> * Same as a domain's dirty_cpumask but limited to
> * this p2m and those physical cpus whose vcpu's are in
> @@ -223,9 +220,6 @@ struct p2m_domain {
> */
> p2m_access_t default_access;
>
> -/* Pages used to construct the p2m */
> -struct page_list_head pages;
> -
> /* Host p2m: Log-dirty ranges registered for the domain. */
> struct rangeset *logdirty_ranges;
>
> @@ -233,6 +227,12 @@ struct p2m_domain {
> bool global_logdirty;
>
> #ifdef CONFIG_HVM
> +/* Translated domain: p2m mapping */
> +pagetable_tphys_table;
> +
> +/* Pages used to construct the p2m */
> +struct page_list_head pages;
> +
> /* Alternate p2m: count of vcpu's currently using this p2m. */
> atomic_t active_vcpus;
>
RE: Ping: [PATCH v5] IOMMU: make DMA containment of quarantined devices optional
> From: Jan Beulich
> Sent: Tuesday, July 6, 2021 3:43 PM
>
> On 26.05.2021 10:19, Jan Beulich wrote:
> > IOMMU: make DMA containment of quarantined devices optional
> >
> > Containing still in flight DMA was introduced to work around certain
> > devices / systems hanging hard upon hitting a "not-present" IOMMU fault.
> > Passing through (such) devices (on such systems) is inherently insecure
> > (as guests could easily arrange for IOMMU faults of any kind to occur).
> > Defaulting to a mode where admins may not even become aware of issues
> > with devices can be considered undesirable. Therefore convert this mode
> > of operation to an optional one, not one enabled by default.
> >
> > This involves resurrecting code commit ea38867831da ("x86 / iommu: set
> > up a scratch page in the quarantine domain") did remove, in a slightly
> > extended and abstracted fashion. Here, instead of reintroducing a pretty
> > pointless use of "goto" in domain_context_unmap(), and instead of making
> > the function (at least temporarily) inconsistent, take the opportunity
> > and replace the other similarly pointless "goto" as well.
> >
> > In order to key the re-instated bypasses off of there (not) being a root
> > page table this further requires moving the allocate_domain_resources()
> > invocation from reassign_device() to amd_iommu_setup_domain_device()
> (or
> > else reassign_device() would allocate a root page table anyway); this is
> > benign to the second caller of the latter function.
> >
> > In VT-d's domain_context_unmap(), instead of adding yet another
> > "goto out" when all that's wanted is a "return", eliminate the "out"
> > label at the same time.
> >
> > Take the opportunity and also limit the control to builds supporting
> > PCI.
> >
> > Signed-off-by: Jan Beulich
>
> May I please ask for feedback here? While I consider it too late to
> get back fundamental objections (such should have been voiced
> earlier), I'm still willing to accept such if they come with an
> understandable reason and are backed by a majority, in which case
> I'd (not very happily) drop the patch despite my concerns with the
> original default chosen when the scratch-page variant of quarantining
> was introduced. But I'm not going to give up on this merely because
> of not getting any feedback at all; instead I'd then also have this
> fall under "lazy consensus", if need be.
>
> Jan
Reviewed-by: Kevin Tian
>
> > ---
> > v5: IOMMU_quarantine_fault -> IOMMU_quarantine_basic,
> > IOMMU_quarantine_write_fault -> IOMMU_quarantine_scratch_page.
> > Amend command line description to clarify tool stack based
> > quarantining mode when "iommu=no-quarantine". Fully
> > s/dummy/scratch/. Re-base.
> > v4: "full" -> "scratch_page". Duplicate Kconfig help text into command
> > line doc. Re-base.
> > v3: IOMMU_quarantine_basic -> IOMMU_quarantine_fault,
> > IOMMU_quarantine_full -> IOMMU_quarantine_write_fault. Kconfig
> > option (choice) to select default. Limit to HAS_PCI.
> > v2: Don't use true/false. Introduce QUARANTINE_SKIP() (albeit I'm not
> > really convinced this is an improvement). Add comment.
> >
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -1364,7 +1364,7 @@ detection of systems known to misbehave
> > > Default: `new` unless directed-EOI is supported
> >
> > ### iommu
> > -= List of [ , verbose, debug, force, required, quarantine,
> > += List of [ , verbose, debug, force, required,
> > quarantine[=scratch-
> page],
> > sharept, intremap, intpost, crash-disable,
> > snoop, qinval, igfx, amd-iommu-perdev-intremap,
> > dom0-{passthrough,strict} ]
> > @@ -1402,11 +1402,32 @@ boolean (e.g. `iommu=no`) can override t
> > will prevent Xen from booting if IOMMUs aren't discovered and enabled
> > successfully.
> >
> > -* The `quarantine` boolean can be used to control Xen's behavior when
> > -de-assigning devices from guests. If enabled (the default), Xen always
> > +* The `quarantine` option can be used to control Xen's behavior when
> > +de-assigning devices from guests.
> > +
> > +When a PCI device is assigned to an untrusted domain, it is possible
> > +for that domain to program the device to DMA to an arbitrary address.
> > +The IOMMU is used to protect the host from malicious DMA by making
> > +sure that the device addresses can only target memory assigned to the
> > +guest. However, when the guest domain is torn down, assigning the
> > +device back to the hardware domain would allow any in-flight DMA to
> > +potentially target critical host data. To avoid this, quarantining
> > +should be enabled. Quarantining can be done in two ways: In its basic
> > +form, all in-flight DMA will simply be forced to encounter IOMMU
> > +faults. Since there are systems where doing so can cause host lockup,
> > +an alternative form is
[PATCH] tools/libxc: use uint32_t for pirq in xc_domain_irq_permission
Current unit8_t for pirq argument in this interface is too restrictive
causing failures on modern hardware with lots of GSIs. That extends down to
XEN_DOMCTL_irq_permission ABI structure where it needs to be fixed up
as well. Internal Xen structures appear to be fine. Existing users of
the interface in tree (libxl, ocaml and python bindings) are already using
int for pirq representation that should be wide enough.
Domctl interface version is needed to be bumped with this change but that
was already done by 918b8842a8 ("arm64: Change type of hsr, cpsr, spsr_el1
to uint64_t") in this release cycle.
Signed-off-by: Igor Druzhinin
---
tools/include/xenctrl.h | 2 +-
tools/libs/ctrl/xc_domain.c | 2 +-
tools/ocaml/libs/xc/xenctrl_stubs.c | 2 +-
xen/include/public/domctl.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 2a7c836..8974747 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1385,7 +1385,7 @@ int xc_domain_ioport_permission(xc_interface *xch,
int xc_domain_irq_permission(xc_interface *xch,
uint32_t domid,
- uint8_t pirq,
+ uint32_t pirq,
uint8_t allow_access);
int xc_domain_iomem_permission(xc_interface *xch,
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index 7d11884..8e4ffd0 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -1384,7 +1384,7 @@ int xc_vcpu_setcontext(xc_interface *xch,
int xc_domain_irq_permission(xc_interface *xch,
uint32_t domid,
- uint8_t pirq,
+ uint32_t pirq,
uint8_t allow_access)
{
DECLARE_DOMCTL;
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index 6e4bc56..e5837e6 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -1077,7 +1077,7 @@ CAMLprim value stub_xc_domain_irq_permission(value xch,
value domid,
value pirq, value allow)
{
CAMLparam4(xch, domid, pirq, allow);
- uint8_t c_pirq;
+ uint32_t c_pirq;
uint8_t c_allow;
int ret;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 4dbf107..277478e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -441,7 +441,7 @@ struct xen_domctl_setdebugging {
/* XEN_DOMCTL_irq_permission */
struct xen_domctl_irq_permission {
-uint8_t pirq;
+uint32_t pirq;
uint8_t allow_access;/* flag to specify enable/disable of IRQ access */
};
--
2.7.4
[xen-unstable-smoke test] 163372: regressions - trouble: blocked/fail
flight 163372 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163372/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days9 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
[xen-unstable-smoke test] 163366: regressions - trouble: blocked/fail
flight 163366 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163366/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days8 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
[qemu-mainline test] 163327: regressions - FAIL
flight 163327 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/163327/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 163321 test-amd64-amd64-qemuu-freebsd12-amd64 13 guest-startfail REGR. vs. 163321 test-amd64-i386-qemuu-rhel6hvm-amd 12 redhat-install fail REGR. vs. 163321 test-amd64-amd64-libvirt-xsm 14 guest-start fail REGR. vs. 163321 test-amd64-i386-freebsd10-i386 13 guest-startfail REGR. vs. 163321 test-amd64-amd64-libvirt 14 guest-start fail REGR. vs. 163321 test-amd64-i386-freebsd10-amd64 13 guest-start fail REGR. vs. 163321 test-amd64-i386-libvirt-xsm 14 guest-start fail REGR. vs. 163321 test-amd64-i386-libvirt 14 guest-start fail REGR. vs. 163321 test-amd64-amd64-libvirt-pair 25 guest-start/debian fail REGR. vs. 163321 test-amd64-i386-libvirt-pair 25 guest-start/debian fail REGR. vs. 163321 test-amd64-amd64-qemuu-nested-amd 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-i386-qemuu-rhel6hvm-intel 12 redhat-install fail REGR. vs. 163321 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail REGR. vs. 163321 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-amd64-xl-qcow212 debian-di-installfail REGR. vs. 163321 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 163321 test-amd64-amd64-libvirt-vhd 12 debian-di-installfail REGR. vs. 163321 test-amd64-i386-xl-qemuu-win7-amd64 12 windows-install fail REGR. vs. 163321 test-amd64-i386-xl-qemuu-ws16-amd64 12 windows-install fail REGR. vs. 163321 test-amd64-amd64-xl-qemuu-ws16-amd64 12 windows-install fail REGR. vs. 163321 test-arm64-arm64-libvirt-xsm 14 guest-start fail REGR. vs. 163321 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 163321 test-armhf-armhf-xl-vhd 12 debian-di-installfail REGR. vs. 163321 test-armhf-armhf-libvirt 14 guest-start fail REGR. vs. 163321 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 163321 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15
[ovmf test] 163340: regressions - FAIL
flight 163340 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/163340/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf 0a6b303dcedb7af238ad485d545802befb797b3a baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 32 days Failing since162368 2021-06-04 15:42:59 Z 32 days 91 attempts Testing same since 163340 2021-07-06 15:40:15 Z0 days1 attempts People who touched revisions under test: Abner Chang Agrawal, Sachin Alexandru Elisei Anthony PERARD Ard Biesheuvel Corvin Köhne Daniel Schaefer Daoxiang Li Dov Murik DunTan gaoliming Guo Dong Hao A Wu Jian J Wang Kaaira Gupta Ken Lautner Kenneth Lautner Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Loo Tung Lun Loo, Tung Lun Manickavasakam Karpagavinayagam Maurice Ma Neal Gompa Ni, Ray Patrick Rudolph Pierre Gondois Ray Ni Rebecca Cran Rebecca Cran Sachin Agrawal Sami Mujawar Scottie Kuo Sean Brogan Sean Brogan Sheng Wei Sumana Venur Sunil V L xueshengfeng Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 3335 lines long.)
[xen-unstable-smoke bisection] complete build-arm64-xsm
branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-arm64-xsm testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 918b8842a852e0e7446286f546724b1c63c56c66 Bug not present: 4473f3601098a2c3cf5ab89d5a29504772985e3a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/163364/ commit 918b8842a852e0e7446286f546724b1c63c56c66 Author: Michal Orzel Date: Mon Jul 5 08:39:52 2021 +0200 arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. Modify type of hsr, cpsr, spsr_el1 to uint64_t. Previously we relied on the padding after spsr_el1. As we removed the padding, modify the union to be 64bit so we don't corrupt spsr_fiq. No need to modify the assembly code because the accesses were based on 64bit registers as there was a 32bit padding after spsr_el1. Remove 32bit padding in cpu_user_regs before spsr_fiq as it is no longer needed due to upper union being 64bit now. Add 64bit padding in cpu_user_regs before spsr_el1 because the kernel frame should be 16-byte aligned. Change type of cpsr to uint64_t in the public outside interface "public/arch-arm.h" to allow ABI compatibility between 32bit and 64bit. Increment XEN_DOMCTL_INTERFACE_VERSION. Change type of cpsr to uint64_t in the public outside interface "public/vm_event.h" to allow ABI compatibility between 32bit and 64bit. Signed-off-by: Michal Orzel Reviewed-by: Bertrand Marquis Reviewed-by: Julien Grall For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/163364.bisection-summary --basis-template=163326 --blessings=real,real-bisect,real-retry xen-unstable-smoke build-arm64-xsm xen-build Searching for failure / basis pass: 163361 fail [host=rochester0] / 163326 [host=laxton0] 163314 [host=laxton0] 163310 [host=laxton0] 163230 [host=laxton0] 163225 [host=laxton0] 163183 [host=laxton1] 163182 ok. Failure / basis pass flights: 163361 / 163182 Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 Basis pass 7ea428895af2840d85c524f0bd11a38aac308308 f8582da0417660269bec69e399f8667f761e886b Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#7ea428895af2840d85c524f0bd11a38aac308308-136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 git://xenbits.xen.org/xen.git#f8582da0417660269bec69e399f8667f761e886b-f17a73b3c0264c62dd6b5dae01ed621c051c3038 Loaded 19968 nodes in revision graph Searching for test results: 163182 pass 7ea428895af2840d85c524f0bd11a38aac308308 f8582da0417660269bec69e399f8667f761e886b 163183 [host=laxton1] 163225 [host=laxton0] 163230 [host=laxton0] 163310 [host=laxton0] 163314 [host=laxton0] 163326 [host=laxton0] 163328 [host=laxton0] 163332 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 163336 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 163345 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 163348 pass 7ea428895af2840d85c524f0bd11a38aac308308 f8582da0417660269bec69e399f8667f761e886b 163349 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 163350 pass 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 74d044d51b19bb697eac5c3deafa140f6afafec8 163351 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 163353 pass 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 09e2cd69956fe529bfc3d53dae477b44eff217d1 163354 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 c8f88810db2a25d6aacf65c1c60bc4f5d848a483 163355 pass 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4473f3601098a2c3cf5ab89d5a29504772985e3a 163356 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 918b8842a852e0e7446286f546724b1c63c56c66 163357 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823
[xen-unstable-smoke test] 163361: regressions - trouble: blocked/fail
flight 163361 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163361/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days7 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
[xen-unstable test] 163323: tolerable FAIL - PUSHED
flight 163323 xen-unstable real [real] flight 163352 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/163323/ http://logs.test-lab.xenproject.org/osstest/logs/163352/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 163352-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 163313 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 163313 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 163313 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 163313 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 163313 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 163313 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 163313 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 163313 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 163313 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 163313 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 163313 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-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-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-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-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: xen 44e8904ebfbc57ba0950c40b9d3a28507b553e4e baseline version: xen 383b41974d5543b62f3181d216070fe3691fb130 Last test of basis 163313 2021-07-05 14:38:57 Z1 days Testing same since 163323 2021-07-06 04:40:42 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Jan
[linux-linus test] 163325: regressions - FAIL
flight 163325 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/163325/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-arm64-arm64-xl-seattle 12 debian-install fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 12 debian-install fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 12 debian-install fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 12 debian-install fail REGR. vs. 152332 test-armhf-armhf-examine 8 reboot fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 12 debian-install fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-arm64-arm64-xl 12 debian-install fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 12 debian-install fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 152332 test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 152332 test-armhf-armhf-libvirt-raw 8 xen-boot fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-armhf-armhf-xl-cubietruck 12 debian-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 12 debian-di-installfail REGR. vs. 152332 test-armhf-armhf-xl-credit2 8 xen-boot fail REGR. vs. 152332 test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 152332 test-armhf-armhf-xl-multivcpu 12 debian-install fail REGR. vs. 152332 test-armhf-armhf-xl-arndale 8 xen-boot fail REGR. vs. 152332 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 152332 test-armhf-armhf-xl-rtds 8 xen-boot fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332
[xen-unstable-smoke test] 163357: regressions - trouble: blocked/fail
flight 163357 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163357/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days6 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Hi Will and Robin, On 7/6/2021 10:06 AM, Will Deacon wrote: On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote: On 2021-07-06 15:05, Christoph Hellwig wrote: On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: FWIW I was pondering the question of whether to do something along those lines or just scrap the default assignment entirely, so since I hadn't got round to saying that I've gone ahead and hacked up the alternative (similarly untested) for comparison :) TBH I'm still not sure which one I prefer... Claire did implement something like your suggestion originally, but I don't really like it as it doesn't scale for adding multiple global pools, e.g. for the 64-bit addressable one for the various encrypted secure guest schemes. Ah yes, that had slipped my mind, and it's a fair point indeed. Since we're not concerned with a minimal fix for backports anyway I'm more than happy to focus on Will's approach. Another thing is that that looks to take us a quiet step closer to the possibility of dynamically resizing a SWIOTLB pool, which is something that some of the hypervisor protection schemes looking to build on top of this series may want to explore at some point. Ok, I'll split that nasty diff I posted up into a reviewable series and we can take it from there. For what it's worth, I attempted to boot Will's diff on top of Konrad's devel/for-linus-5.14 and it did not work; in fact, I got no output on my monitor period, even with earlyprintk=, and I do not think this machine has a serial console. Robin's fix does work, it survived ten reboots with no issues getting to X and I do not see the KASAN and slub debug messages anymore but I understand that this is not the preferred solution it seems (although Konrad did want to know if it works). I am happy to test any further patches or follow ups as needed, just keep me on CC. Cheers, Nathan
Re: [PATCH v2 4/4] bus: Make remove callback return void
Hello Bjorn,
On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > index c1404d3dae2c..7f6fac618ab2 100644
> > --- a/drivers/rpmsg/rpmsg_core.c
> > +++ b/drivers/rpmsg/rpmsg_core.c
> > @@ -530,7 +530,7 @@ static int rpmsg_dev_probe(struct device *dev)
> > return err;
> > }
> >
> > -static int rpmsg_dev_remove(struct device *dev)
> > +static void rpmsg_dev_remove(struct device *dev)
> > {
> > struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> > struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
> > @@ -546,8 +546,6 @@ static int rpmsg_dev_remove(struct device *dev)
> >
> > if (rpdev->ept)
> > rpmsg_destroy_ept(rpdev->ept);
> > -
> > - return err;
>
> This leaves err assigned but never used, but I don't mind following up
> with a patch cleaning that up after this has landed.
Ah, good catch. If I send out a v3 I will fold the following into this
patch:
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index 7f6fac618ab2..9151836190ce 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -534,10 +534,9 @@ static void rpmsg_dev_remove(struct device *dev)
{
struct rpmsg_device *rpdev = to_rpmsg_device(dev);
struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
- int err = 0;
if (rpdev->ops->announce_destroy)
- err = rpdev->ops->announce_destroy(rpdev);
+ rpdev->ops->announce_destroy(rpdev);
if (rpdrv->remove)
rpdrv->remove(rpdev);
Maybe .announce_destroy() should then be changed to return void, too?
Something like:
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index a76c344253bf..d5204756714c 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -40,7 +40,7 @@ struct rpmsg_device_ops {
struct rpmsg_channel_info chinfo);
int (*announce_create)(struct rpmsg_device *ept);
- int (*announce_destroy)(struct rpmsg_device *ept);
+ void (*announce_destroy)(struct rpmsg_device *ept);
};
/**
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 8e49a3bacfc7..4e05994634f8 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -340,7 +340,7 @@ static int virtio_rpmsg_announce_create(struct rpmsg_device
*rpdev)
return err;
}
-static int virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
+static void virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
{
struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
struct virtproc_info *vrp = vch->vrp;
@@ -360,8 +360,6 @@ static int virtio_rpmsg_announce_destroy(struct
rpmsg_device *rpdev)
if (err)
dev_err(dev, "failed to announce service %d\n", err);
}
-
- return err;
}
static const struct rpmsg_device_ops virtio_rpmsg_ops = {
though it's not obvious for me that the last hunk is sensible. (OTOH the
return code is ignored anyhow as rpmsg_dev_remove() is the only caller.
Best regards and thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[xen-unstable-smoke test] 163351: regressions - trouble: blocked/fail
flight 163351 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163351/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days5 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
[xen-unstable-smoke test] 163345: regressions - trouble: blocked/fail
flight 163345 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163345/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days4 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
[xen-unstable-smoke bisection] complete build-amd64
branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-amd64 testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 918b8842a852e0e7446286f546724b1c63c56c66 Bug not present: 4473f3601098a2c3cf5ab89d5a29504772985e3a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/163347/ commit 918b8842a852e0e7446286f546724b1c63c56c66 Author: Michal Orzel Date: Mon Jul 5 08:39:52 2021 +0200 arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t AArch64 registers are 64bit whereas AArch32 registers are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when reading sysregs which can correspond to uint64_t or uint32_t. Even though many AArch64 registers have upper 32bit reserved it does not mean that they can't be widen in the future. Modify type of hsr, cpsr, spsr_el1 to uint64_t. Previously we relied on the padding after spsr_el1. As we removed the padding, modify the union to be 64bit so we don't corrupt spsr_fiq. No need to modify the assembly code because the accesses were based on 64bit registers as there was a 32bit padding after spsr_el1. Remove 32bit padding in cpu_user_regs before spsr_fiq as it is no longer needed due to upper union being 64bit now. Add 64bit padding in cpu_user_regs before spsr_el1 because the kernel frame should be 16-byte aligned. Change type of cpsr to uint64_t in the public outside interface "public/arch-arm.h" to allow ABI compatibility between 32bit and 64bit. Increment XEN_DOMCTL_INTERFACE_VERSION. Change type of cpsr to uint64_t in the public outside interface "public/vm_event.h" to allow ABI compatibility between 32bit and 64bit. Signed-off-by: Michal Orzel Reviewed-by: Bertrand Marquis Reviewed-by: Julien Grall For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build --summary-out=tmp/163347.bisection-summary --basis-template=163326 --blessings=real,real-bisect,real-retry xen-unstable-smoke build-amd64 xen-build Searching for failure / basis pass: 163336 fail [host=himrod1] / 163326 [host=himrod2] 163314 ok. Failure / basis pass flights: 163336 / 163314 (tree with no url: minios) (tree in basispass but not in latest: ovmf) (tree in basispass but not in latest: qemu) (tree in basispass but not in latest: seabios) Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 Basis pass 7ea428895af2840d85c524f0bd11a38aac308308 44e8904ebfbc57ba0950c40b9d3a28507b553e4e Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#7ea428895af2840d85c524f0bd11a38aac308308-136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 git://xenbits.xen.org/xen.git#44e8904ebfbc57ba0950c40b9d3a28507b553e4e-f17a73b3c0264c62dd6b5dae01ed621c051c3038 Loaded 19986 nodes in revision graph Searching for test results: 163314 pass 7ea428895af2840d85c524f0bd11a38aac308308 44e8904ebfbc57ba0950c40b9d3a28507b553e4e 163326 [host=himrod2] 163328 [host=himrod2] 163329 [host=himrod2] 163330 [host=himrod2] 163331 [host=himrod2] 16 [host=himrod2] 163332 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 163334 [host=himrod2] 163335 pass 7ea428895af2840d85c524f0bd11a38aac308308 44e8904ebfbc57ba0950c40b9d3a28507b553e4e 163337 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 163338 pass 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 09e2cd69956fe529bfc3d53dae477b44eff217d1 163336 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 f17a73b3c0264c62dd6b5dae01ed621c051c3038 163339 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 c8f88810db2a25d6aacf65c1c60bc4f5d848a483 163341 pass 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4473f3601098a2c3cf5ab89d5a29504772985e3a 163342 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 918b8842a852e0e7446286f546724b1c63c56c66 163343 pass 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4473f3601098a2c3cf5ab89d5a29504772985e3a 163344 fail 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 918b8842a852e0e7446286f546724b1c63c56c66 163346 pass 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4473f3601098a2c3cf5ab89d5a29504772985e3a 163347 fail
Re: [PATCH] arm: Fix arch_initialise_vcpu to be unsupported
Hi Michal,
> On 6 Jul 2021, at 11:28, Michal Orzel wrote:
>
> Function arch_initialise_vcpu is not reachable as the
> VCPUOP_initialise is an unsupported operation on arm.
> Modify the function by adding ASSERT_UNREACHABLE() and
> returning -EOPNOTSUPP.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Michal Orzel
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> xen/arch/arm/domain.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index c021a03c61..a2aa8b77ad 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -923,7 +923,8 @@ int arch_set_info_guest(
>
> int arch_initialise_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> -return default_initialise_vcpu(v, arg);
> +ASSERT_UNREACHABLE();
> +return -EOPNOTSUPP;
> }
>
> int arch_vcpu_reset(struct vcpu *v)
> --
> 2.29.0
>
Re: [PATCH] xen/arm: smmuv1: Switch from kzalloc_array(..) to devm_kcalloc(..)
Hi Rahul, > On 6 Jul 2021, at 11:53, Rahul Singh wrote: > > Switch from kzalloc_array(..) to devm_kcalloc(..) when allocating the > SMR to make code coherent. > > Signed-off-by: Rahul Singh Reviewed-by: Bertrand Marquis Cheers Bertrand > --- > xen/drivers/passthrough/arm/smmu.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/smmu.c > b/xen/drivers/passthrough/arm/smmu.c > index da2cd457d7..658c40433c 100644 > --- a/xen/drivers/passthrough/arm/smmu.c > +++ b/xen/drivers/passthrough/arm/smmu.c > @@ -149,7 +149,8 @@ typedef enum irqreturn irqreturn_t; > #define kzalloc(size, flags) _xzalloc(size, sizeof(void *)) > #define devm_kzalloc(dev, size, flags)_xzalloc(size, sizeof(void *)) > #define kmalloc_array(size, n, flags) _xmalloc_array(size, sizeof(void *), n) > -#define kzalloc_array(size, n, flags)_xzalloc_array(size, > sizeof(void *), n) > +#define devm_kcalloc(dev, n, size, flags)\ > + _xzalloc_array(size, sizeof(void *), n) > > static void __iomem *devm_ioremap_resource(struct device *dev, > struct resource *res) > @@ -,7 +2223,8 @@ static int arm_smmu_device_cfg_probe(struct > arm_smmu_device *smmu) > smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT; > > /* Zero-initialised to mark as invalid */ > - smmu->smrs = kzalloc_array(sizeof(*smmu->smrs), size, > GFP_KERNEL); > + smmu->smrs = devm_kcalloc(smmu->dev, size, sizeof(*smmu->smrs), > + GFP_KERNEL); > if (!smmu->smrs) > return -ENOMEM; > > -- > 2.17.1 >
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote: > On 2021-07-06 15:05, Christoph Hellwig wrote: > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: > > > FWIW I was pondering the question of whether to do something along those > > > lines or just scrap the default assignment entirely, so since I hadn't got > > > round to saying that I've gone ahead and hacked up the alternative > > > (similarly untested) for comparison :) > > > > > > TBH I'm still not sure which one I prefer... > > > > Claire did implement something like your suggestion originally, but > > I don't really like it as it doesn't scale for adding multiple global > > pools, e.g. for the 64-bit addressable one for the various encrypted > > secure guest schemes. > > Ah yes, that had slipped my mind, and it's a fair point indeed. Since we're > not concerned with a minimal fix for backports anyway I'm more than happy to > focus on Will's approach. Another thing is that that looks to take us a > quiet step closer to the possibility of dynamically resizing a SWIOTLB pool, > which is something that some of the hypervisor protection schemes looking to > build on top of this series may want to explore at some point. Ok, I'll split that nasty diff I posted up into a reviewable series and we can take it from there. Will
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote: > On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote: > > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote: > > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: > > > > FWIW I was pondering the question of whether to do something along > > > > those > > > > lines or just scrap the default assignment entirely, so since I hadn't > > > > got > > > > round to saying that I've gone ahead and hacked up the alternative > > > > (similarly untested) for comparison :) > > > > > > > > TBH I'm still not sure which one I prefer... > > > > > > Claire did implement something like your suggestion originally, but > > > I don't really like it as it doesn't scale for adding multiple global > > > pools, e.g. for the 64-bit addressable one for the various encrypted > > > secure guest schemes. > > > > Couple of things: > > - I am not pushing to Linus the Claire's patchset until we have a > >resolution on this. I hope you all agree that is a sensible way > >forward as much as I hate doing that. > > Sure, it's a pity but we could clearly use a bit more time to get these > just right and we've run out of time for 5.14. > > I think the main question I have is how would you like to see patches for > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else? Yes that would be perfect. If there are any dependencies on the rc1, I can rebase it on top of that. > > Cheers, > > Will
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote: > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: > > > FWIW I was pondering the question of whether to do something along those > > > lines or just scrap the default assignment entirely, so since I hadn't > > > got > > > round to saying that I've gone ahead and hacked up the alternative > > > (similarly untested) for comparison :) > > > > > > TBH I'm still not sure which one I prefer... > > > > Claire did implement something like your suggestion originally, but > > I don't really like it as it doesn't scale for adding multiple global > > pools, e.g. for the 64-bit addressable one for the various encrypted > > secure guest schemes. > > Couple of things: > - I am not pushing to Linus the Claire's patchset until we have a >resolution on this. I hope you all agree that is a sensible way >forward as much as I hate doing that. Sure, it's a pity but we could clearly use a bit more time to get these just right and we've run out of time for 5.14. I think the main question I have is how would you like to see patches for 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else? Cheers, Will
[xen-unstable-smoke test] 163336: regressions - trouble: blocked/fail
flight 163336 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163336/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days3 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06/07/2021 16:22, Jan Beulich wrote: > On 06.07.2021 17:13, Jan Beulich wrote: >> On 06.07.2021 16:11, Olaf Hering wrote: >>> Am Tue, 6 Jul 2021 14:58:04 +0200 >>> schrieb Olaf Hering : >>> the reporting is broken since a while >>> A quick check on a Dell T320 with E5-2430L, which does not have "Page >>> Modification Logging", indicates that staging-4.5 appears to work, but >>> reporting in staging-4.6 is broken. >> Not surprising at all, considering PML support was added in 4.6. > Or perhaps still surprising, as the functions involved there don't > appear to be bypassing any core logic, so after some looking around > I can't say I see anything that's obviously wrong. > > Oh, and I notice only now the "not" in your original reply, which > renders my earlier statement completely pointless anyway. I'm sorry. Ok, so my observations of dirty_count being reliable during development of migration v2 appears to be correct, and something regressed in the dev window where it got committed upstream... That is suspicious. ~Andrew
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On 2021-07-06 15:05, Christoph Hellwig wrote: On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: FWIW I was pondering the question of whether to do something along those lines or just scrap the default assignment entirely, so since I hadn't got round to saying that I've gone ahead and hacked up the alternative (similarly untested) for comparison :) TBH I'm still not sure which one I prefer... Claire did implement something like your suggestion originally, but I don't really like it as it doesn't scale for adding multiple global pools, e.g. for the 64-bit addressable one for the various encrypted secure guest schemes. Ah yes, that had slipped my mind, and it's a fair point indeed. Since we're not concerned with a minimal fix for backports anyway I'm more than happy to focus on Will's approach. Another thing is that that looks to take us a quiet step closer to the possibility of dynamically resizing a SWIOTLB pool, which is something that some of the hypervisor protection schemes looking to build on top of this series may want to explore at some point. Robin.
[ovmf test] 163324: regressions - FAIL
flight 163324 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/163324/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359 version targeted for testing: ovmf 44ced03798d3af47577af3e7a865be33383766d0 baseline version: ovmf c410ad4da4b7785170d3d42a3ba190c2caac6feb Last test of basis 162359 2021-06-04 03:40:08 Z 32 days Failing since162368 2021-06-04 15:42:59 Z 31 days 90 attempts Testing same since 163312 2021-07-05 12:41:15 Z1 days3 attempts People who touched revisions under test: Abner Chang Agrawal, Sachin Alexandru Elisei Anthony PERARD Ard Biesheuvel Corvin Köhne Daniel Schaefer Daoxiang Li Dov Murik DunTan gaoliming Guo Dong Hao A Wu Jian J Wang Kaaira Gupta Ken Lautner Kenneth Lautner Kun Qin Laszlo Ersek Leif Lindholm Liming Gao Loo Tung Lun Loo, Tung Lun Manickavasakam Karpagavinayagam Maurice Ma Ni, Ray Patrick Rudolph Pierre Gondois Ray Ni Rebecca Cran Rebecca Cran Sachin Agrawal Sami Mujawar Scottie Kuo Sean Brogan Sean Brogan Sumana Venur Sunil V L xueshengfeng Zhiguang Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 3263 lines long.)
Re: [PATCH] tools: Fix CPSR/SPSR print size
> On 6 Jul 2021, at 16:25, Julien Grall wrote:
>
>
>
> On 06/07/2021 16:23, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 6 Jul 2021, at 16:15, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> Thanks for the fix. I forgot to check the full tools build when sending the
>>> first fix :(.
>>>
>>> On 06/07/2021 16:09, Bertrand Marquis wrote:
With the changes of register size introduced in
918b8842a852e0e7446286f546724b1c63c56c66, CPSR and SPSR are now stored
as 64bit values.
Fix the print size to use 64bit type.
>>>
>>> Can you add a fixes tag? This makes easier to find bug fix in the tree.
>>>
>>> For this patch it would be:
>>>
>>> Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
>>> uint64_t")
>> Sure. Patch incoming in the next minutes.
>
> I can fix it on commit.
Up to you, I also just sent a v2 if it is easier :-)
Cheers
Bertrand
>
>>>
Signed-off-by: Bertrand Marquis
>>>
>>> Just to confirm, with this patch and mine the tools build successfully on
>>> 32-bit and 64-bit?
>> Yes I have a full build running with both patches added for arm32, arm64 and
>> x86_64.
>
> Perfect!
>
> Acked-by: Julien Grall
>
> Cheers,
>
> --
> Julien Grall
[PATCH v2] tools: Fix CPSR/SPSR print size
918b8842a852 changed CPSR and SPSR to be stored as 64bit values.
This is fixing the print size in some tools to use 64bit type.
Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t")
Signed-off-by: Bertrand Marquis
---
Changes in v2:
- update commit message
- add Fixes
---
tools/libs/guest/xg_dom_arm.c | 4 ++--
tools/xentrace/xenctx.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libs/guest/xg_dom_arm.c b/tools/libs/guest/xg_dom_arm.c
index 01e85e0ea9..5e3b76355e 100644
--- a/tools/libs/guest/xg_dom_arm.c
+++ b/tools/libs/guest/xg_dom_arm.c
@@ -140,7 +140,7 @@ static int vcpu_arm32(struct xc_dom_image *dom)
ctxt->flags = VGCF_online;
-DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
+DOMPRINTF("Initial state CPSR %#"PRIx64" PC %#"PRIx32,
ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
rc = xc_vcpu_setcontext(dom->xch, dom->guest_domid, 0, _ctx);
@@ -182,7 +182,7 @@ static int vcpu_arm64(struct xc_dom_image *dom)
ctxt->flags = VGCF_online;
-DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx64,
+DOMPRINTF("Initial state CPSR %#"PRIx64" PC %#"PRIx64,
ctxt->user_regs.cpsr, ctxt->user_regs.pc64);
rc = xc_vcpu_setcontext(dom->xch, dom->guest_domid, 0, _ctx);
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 972f473dbf..85ba0c0fa6 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -556,7 +556,7 @@ static void print_ctx_32(vcpu_guest_context_t *ctx)
printf("PC: %08"PRIx32, regs->pc32);
print_symbol(regs->pc32, KERNEL_TEXT_ADDR);
printf("\n");
-printf("CPSR: %08"PRIx32"\n", regs->cpsr);
+printf("CPSR: %08"PRIx64"\n", regs->cpsr);
printf("USR: SP:%08"PRIx32" LR:%08"PRIx32"\n",
regs->sp_usr, regs->lr_usr);
printf("SVC: SPSR:%08"PRIx32" SP:%08"PRIx32" LR:%08"PRIx32"\n",
@@ -614,8 +614,8 @@ static void print_ctx_64(vcpu_guest_context_t *ctx)
printf("LR: %016"PRIx64"\n", regs->x30);
printf("ELR_EL1: %016"PRIx64"\n", regs->elr_el1);
-printf("CPSR: %08"PRIx32"\n", regs->cpsr);
-printf("SPSR_EL1: %08"PRIx32"\n", regs->spsr_el1);
+printf("CPSR: %08"PRIx64"\n", regs->cpsr);
+printf("SPSR_EL1: %08"PRIx64"\n", regs->spsr_el1);
printf("SP_EL0: %016"PRIx64"\n", regs->sp_el0);
printf("SP_EL1: %016"PRIx64"\n", regs->sp_el1);
--
2.17.1
Re: [PATCH] tools: Fix CPSR/SPSR print size
On 06/07/2021 16:23, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 6 Jul 2021, at 16:15, Julien Grall wrote:
Hi Bertrand,
Thanks for the fix. I forgot to check the full tools build when sending the
first fix :(.
On 06/07/2021 16:09, Bertrand Marquis wrote:
With the changes of register size introduced in
918b8842a852e0e7446286f546724b1c63c56c66, CPSR and SPSR are now stored
as 64bit values.
Fix the print size to use 64bit type.
Can you add a fixes tag? This makes easier to find bug fix in the tree.
For this patch it would be:
Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t")
Sure. Patch incoming in the next minutes.
I can fix it on commit.
Signed-off-by: Bertrand Marquis
Just to confirm, with this patch and mine the tools build successfully on
32-bit and 64-bit?
Yes I have a full build running with both patches added for arm32, arm64 and
x86_64.
Perfect!
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Re: [PATCH] tools: Fix CPSR/SPSR print size
Hi Julien,
> On 6 Jul 2021, at 16:15, Julien Grall wrote:
>
> Hi Bertrand,
>
> Thanks for the fix. I forgot to check the full tools build when sending the
> first fix :(.
>
> On 06/07/2021 16:09, Bertrand Marquis wrote:
>> With the changes of register size introduced in
>> 918b8842a852e0e7446286f546724b1c63c56c66, CPSR and SPSR are now stored
>> as 64bit values.
>> Fix the print size to use 64bit type.
>
> Can you add a fixes tag? This makes easier to find bug fix in the tree.
>
> For this patch it would be:
>
> Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t")
Sure. Patch incoming in the next minutes.
>
>> Signed-off-by: Bertrand Marquis
>
> Just to confirm, with this patch and mine the tools build successfully on
> 32-bit and 64-bit?
Yes I have a full build running with both patches added for arm32, arm64 and
x86_64.
Cheers
Bertrand
>
> Cheers,
>
> --
> Julien Grall
>
Re: [PATCH] tools/xen-foreign: Update the size for vcpu_guest_{core_regs, context}
Hi Jan,
On 06/07/2021 16:10, Jan Beulich wrote:
On 06.07.2021 16:24, Julien Grall wrote:
On 06/07/2021 15:07, Jan Beulich wrote:
On 06.07.2021 15:20, Julien Grall wrote:
From: Julien Grall
Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t") updated the size of the structure vcpu_guest_core_regs and
indirectly vcpu_guest_context.
On Arm, the two structures are only accessible to the tools and the
hypervisor (and therefore stable). However, they are still checked
I suppose s/stable/not stable/ and ...
by the scripts in tools/include/xen-foreign are not able to understand
that.
Ideally we should rework the scripts so we don't have to update
the size for non-stable structure. But I don't have limited time
... s/don't/only/ ?
Yes I will update.
to spend on the issue. So chose the simple solution and update
the size accordingly.
Note that we need to keep vcpu_guest_core_regs around because
the structure is used by vcpu_guest_context and therefore the
scripts expects the generated header to contain it.
If vcpu_guest_context is also tools-only, why does it need keeping
(for Arm)? IOW can't you drop vcpu_guest_core_regs from the scripts
altogether, and mark vcpu_guest_context with valid sizes for x86
only?
I have tried to use "-" in place of the size but the checker is still
not happy. I didn't find another way without modifying the script...
I don't know the script and I don't have a lot of time to work on the
bug fix. So this is not something I could do this week.
So this leave us to the following options:
1) Someone volunteer to fix the script
2) Revert the patch that broke the build
3) Accept this patch
I would prefer 3) so we have more time to work on making the script a
lot smarter.
Well, if we have no-one who knows the script, and the simple thing
of removing the one obvious line doesn't help, then I agree we want
to go with 3) for now, even if it looks odd to adjust number for
something that's not supposed to be checked in the first place. Of
course I also wouldn't mind 2), as it seems pretty clear that the
patch was insufficiently build-tested.
The series has dragged on for quite a while on the ML. So I would like
to avoid a revert and wait for further rework in the tools side.
Also Bertrand pointed out there is a second fix necessary (I think they
should still live separately). I will wait him to confirm that the
toolstack is building for 32-bit and 64-bit after the two patches are
applied.
Cheers,
--
Julien Grall
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06.07.2021 17:13, Jan Beulich wrote: > On 06.07.2021 16:11, Olaf Hering wrote: >> Am Tue, 6 Jul 2021 14:58:04 +0200 >> schrieb Olaf Hering : >> >>> the reporting is broken since a while >> >> A quick check on a Dell T320 with E5-2430L, which does not have "Page >> Modification Logging", indicates that staging-4.5 appears to work, but >> reporting in staging-4.6 is broken. > > Not surprising at all, considering PML support was added in 4.6. Or perhaps still surprising, as the functions involved there don't appear to be bypassing any core logic, so after some looking around I can't say I see anything that's obviously wrong. Oh, and I notice only now the "not" in your original reply, which renders my earlier statement completely pointless anyway. I'm sorry. Jan
Re: [PATCH] tools: Fix CPSR/SPSR print size
Hi Bertrand,
Thanks for the fix. I forgot to check the full tools build when sending
the first fix :(.
On 06/07/2021 16:09, Bertrand Marquis wrote:
With the changes of register size introduced in
918b8842a852e0e7446286f546724b1c63c56c66, CPSR and SPSR are now stored
as 64bit values.
Fix the print size to use 64bit type.
Can you add a fixes tag? This makes easier to find bug fix in the tree.
For this patch it would be:
Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t")
Signed-off-by: Bertrand Marquis
Just to confirm, with this patch and mine the tools build successfully
on 32-bit and 64-bit?
Cheers,
--
Julien Grall
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06.07.2021 16:11, Olaf Hering wrote: > Am Tue, 6 Jul 2021 14:58:04 +0200 > schrieb Olaf Hering : > >> the reporting is broken since a while > > A quick check on a Dell T320 with E5-2430L, which does not have "Page > Modification Logging", indicates that staging-4.5 appears to work, but > reporting in staging-4.6 is broken. Not surprising at all, considering PML support was added in 4.6. Jan
Re: [PATCH] tools/xen-foreign: Update the size for vcpu_guest_{core_regs, context}
On 06.07.2021 16:24, Julien Grall wrote:
> On 06/07/2021 15:07, Jan Beulich wrote:
>> On 06.07.2021 15:20, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
>>> uint64_t") updated the size of the structure vcpu_guest_core_regs and
>>> indirectly vcpu_guest_context.
>>>
>>> On Arm, the two structures are only accessible to the tools and the
>>> hypervisor (and therefore stable). However, they are still checked
>>
>> I suppose s/stable/not stable/ and ...
>>
>>> by the scripts in tools/include/xen-foreign are not able to understand
>>> that.
>>>
>>> Ideally we should rework the scripts so we don't have to update
>>> the size for non-stable structure. But I don't have limited time
>>
>> ... s/don't/only/ ?
>
> Yes I will update.
>
>>
>>> to spend on the issue. So chose the simple solution and update
>>> the size accordingly.
>>>
>>> Note that we need to keep vcpu_guest_core_regs around because
>>> the structure is used by vcpu_guest_context and therefore the
>>> scripts expects the generated header to contain it.
>>
>> If vcpu_guest_context is also tools-only, why does it need keeping
>> (for Arm)? IOW can't you drop vcpu_guest_core_regs from the scripts
>> altogether, and mark vcpu_guest_context with valid sizes for x86
>> only?
> I have tried to use "-" in place of the size but the checker is still
> not happy. I didn't find another way without modifying the script...
>
> I don't know the script and I don't have a lot of time to work on the
> bug fix. So this is not something I could do this week.
>
> So this leave us to the following options:
>1) Someone volunteer to fix the script
>2) Revert the patch that broke the build
>3) Accept this patch
>
> I would prefer 3) so we have more time to work on making the script a
> lot smarter.
Well, if we have no-one who knows the script, and the simple thing
of removing the one obvious line doesn't help, then I agree we want
to go with 3) for now, even if it looks odd to adjust number for
something that's not supposed to be checked in the first place. Of
course I also wouldn't mind 2), as it seems pretty clear that the
patch was insufficiently build-tested.
Jan
[PATCH] tools: Fix CPSR/SPSR print size
With the changes of register size introduced in
918b8842a852e0e7446286f546724b1c63c56c66, CPSR and SPSR are now stored
as 64bit values.
Fix the print size to use 64bit type.
Signed-off-by: Bertrand Marquis
---
tools/libs/guest/xg_dom_arm.c | 4 ++--
tools/xentrace/xenctx.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libs/guest/xg_dom_arm.c b/tools/libs/guest/xg_dom_arm.c
index 01e85e0ea9..5e3b76355e 100644
--- a/tools/libs/guest/xg_dom_arm.c
+++ b/tools/libs/guest/xg_dom_arm.c
@@ -140,7 +140,7 @@ static int vcpu_arm32(struct xc_dom_image *dom)
ctxt->flags = VGCF_online;
-DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
+DOMPRINTF("Initial state CPSR %#"PRIx64" PC %#"PRIx32,
ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
rc = xc_vcpu_setcontext(dom->xch, dom->guest_domid, 0, _ctx);
@@ -182,7 +182,7 @@ static int vcpu_arm64(struct xc_dom_image *dom)
ctxt->flags = VGCF_online;
-DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx64,
+DOMPRINTF("Initial state CPSR %#"PRIx64" PC %#"PRIx64,
ctxt->user_regs.cpsr, ctxt->user_regs.pc64);
rc = xc_vcpu_setcontext(dom->xch, dom->guest_domid, 0, _ctx);
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index 972f473dbf..85ba0c0fa6 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -556,7 +556,7 @@ static void print_ctx_32(vcpu_guest_context_t *ctx)
printf("PC: %08"PRIx32, regs->pc32);
print_symbol(regs->pc32, KERNEL_TEXT_ADDR);
printf("\n");
-printf("CPSR: %08"PRIx32"\n", regs->cpsr);
+printf("CPSR: %08"PRIx64"\n", regs->cpsr);
printf("USR: SP:%08"PRIx32" LR:%08"PRIx32"\n",
regs->sp_usr, regs->lr_usr);
printf("SVC: SPSR:%08"PRIx32" SP:%08"PRIx32" LR:%08"PRIx32"\n",
@@ -614,8 +614,8 @@ static void print_ctx_64(vcpu_guest_context_t *ctx)
printf("LR: %016"PRIx64"\n", regs->x30);
printf("ELR_EL1: %016"PRIx64"\n", regs->elr_el1);
-printf("CPSR: %08"PRIx32"\n", regs->cpsr);
-printf("SPSR_EL1: %08"PRIx32"\n", regs->spsr_el1);
+printf("CPSR: %08"PRIx64"\n", regs->cpsr);
+printf("SPSR_EL1: %08"PRIx64"\n", regs->spsr_el1);
printf("SP_EL0: %016"PRIx64"\n", regs->sp_el0);
printf("SP_EL1: %016"PRIx64"\n", regs->sp_el1);
--
2.17.1
Re: [PATCH] bus: Make remove callback return void
On 7/6/21 2:50 AM, Uwe Kleine-König wrote:
> --- a/arch/powerpc/platforms/ps3/system-bus.c
> +++ b/arch/powerpc/platforms/ps3/system-bus.c
> @@ -381,7 +381,7 @@ static int ps3_system_bus_probe(struct device *_dev)
> return result;
> }
>
> -static int ps3_system_bus_remove(struct device *_dev)
> +static void ps3_system_bus_remove(struct device *_dev)
> {
> struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
> struct ps3_system_bus_driver *drv;
> @@ -399,7 +399,6 @@ static int ps3_system_bus_remove(struct device *_dev)
> __func__, __LINE__, drv->core.name);
>
> pr_debug(" <- %s:%d: %s\n", __func__, __LINE__, dev_name(>core));
> - return 0;
> }
PS3 part looks fine.
Acked-by: Geoff Levand
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote: > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: > > FWIW I was pondering the question of whether to do something along those > > lines or just scrap the default assignment entirely, so since I hadn't got > > round to saying that I've gone ahead and hacked up the alternative > > (similarly untested) for comparison :) > > > > TBH I'm still not sure which one I prefer... > > Claire did implement something like your suggestion originally, but > I don't really like it as it doesn't scale for adding multiple global > pools, e.g. for the 64-bit addressable one for the various encrypted > secure guest schemes. Couple of things: - I am not pushing to Linus the Claire's patchset until we have a resolution on this. I hope you all agree that is a sensible way forward as much as I hate doing that. - I like Robin's fix as it is simplest looking. Would love to see if it does fix the problem. - Christopher - we can always add multiple pools as the next milestone and just focus on this feature getting tested extensively during this release. - Would it be worth (for future or maybe in another tiny fix) to also add a printk in swiotlb when we de-allocate the buffer so when someone looks through the `dmesg` it becomes much easier to diagnose issues?
[xen-unstable-smoke test] 163332: regressions - trouble: blocked/fail
flight 163332 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163332/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days2 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
Re: [PATCH] tools/xen-foreign: Update the size for vcpu_guest_{core_regs, context}
Hi,
On 06/07/2021 15:07, Jan Beulich wrote:
On 06.07.2021 15:20, Julien Grall wrote:
From: Julien Grall
Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t") updated the size of the structure vcpu_guest_core_regs and
indirectly vcpu_guest_context.
On Arm, the two structures are only accessible to the tools and the
hypervisor (and therefore stable). However, they are still checked
I suppose s/stable/not stable/ and ...
by the scripts in tools/include/xen-foreign are not able to understand
that.
Ideally we should rework the scripts so we don't have to update
the size for non-stable structure. But I don't have limited time
... s/don't/only/ ?
Yes I will update.
to spend on the issue. So chose the simple solution and update
the size accordingly.
Note that we need to keep vcpu_guest_core_regs around because
the structure is used by vcpu_guest_context and therefore the
scripts expects the generated header to contain it.
If vcpu_guest_context is also tools-only, why does it need keeping
(for Arm)? IOW can't you drop vcpu_guest_core_regs from the scripts
altogether, and mark vcpu_guest_context with valid sizes for x86
only?
I have tried to use "-" in place of the size but the checker is still
not happy. I didn't find another way without modifying the script...
I don't know the script and I don't have a lot of time to work on the
bug fix. So this is not something I could do this week.
So this leave us to the following options:
1) Someone volunteer to fix the script
2) Revert the patch that broke the build
3) Accept this patch
I would prefer 3) so we have more time to work on making the script a
lot smarter.
Cheers,
--
Julien Grall
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
Am Tue, 6 Jul 2021 14:58:04 +0200 schrieb Olaf Hering : > the reporting is broken since a while A quick check on a Dell T320 with E5-2430L, which does not have "Page Modification Logging", indicates that staging-4.5 appears to work, but reporting in staging-4.6 is broken. Olaf pgpvrugZq6Cre.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH] tools/xen-foreign: Update the size for vcpu_guest_{core_regs, context}
On 06.07.2021 15:20, Julien Grall wrote:
> From: Julien Grall
>
> Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
> uint64_t") updated the size of the structure vcpu_guest_core_regs and
> indirectly vcpu_guest_context.
>
> On Arm, the two structures are only accessible to the tools and the
> hypervisor (and therefore stable). However, they are still checked
I suppose s/stable/not stable/ and ...
> by the scripts in tools/include/xen-foreign are not able to understand
> that.
>
> Ideally we should rework the scripts so we don't have to update
> the size for non-stable structure. But I don't have limited time
... s/don't/only/ ?
> to spend on the issue. So chose the simple solution and update
> the size accordingly.
>
> Note that we need to keep vcpu_guest_core_regs around because
> the structure is used by vcpu_guest_context and therefore the
> scripts expects the generated header to contain it.
If vcpu_guest_context is also tools-only, why does it need keeping
(for Arm)? IOW can't you drop vcpu_guest_core_regs from the scripts
altogether, and mark vcpu_guest_context with valid sizes for x86
only?
Jan
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: > FWIW I was pondering the question of whether to do something along those > lines or just scrap the default assignment entirely, so since I hadn't got > round to saying that I've gone ahead and hacked up the alternative > (similarly untested) for comparison :) > > TBH I'm still not sure which one I prefer... Claire did implement something like your suggestion originally, but I don't really like it as it doesn't scale for adding multiple global pools, e.g. for the 64-bit addressable one for the various encrypted secure guest schemes.
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
where 'swiotlb' is a global variable indicating whether or not swiotlb
is in use. It's picked up a bit later on by pci_swiotlb_late_init(), which
will call swiotlb_exit() if 'swiotlb' is false.
Now, that used to work fine, because swiotlb_exit() clears
'io_tlb_default_mem' to NULL, but now with the restricted DMA changes, I
think that all the devices which have successfully probed beforehand will
have stale pointers to the freed structure in their 'dev->dma_io_tlb_mem'
field.
Yeah. I don't think we can do that anymore, and I also think it is
a bad idea to start with.
I've had a crack at reworking things along the following lines:
- io_tlb_default_mem now lives in the BSS, the flexible array member
is now a pointer and that part is allocated dynamically (downside of
this is an extra indirection to get at the slots).
- io_tlb_default_mem.nslabs tells you whether the thing is valid
- swiotlb_exit() frees the slots array and clears the rest of the
structure to 0. I also extended it to free the actual slabs, but I'm
not sure why it wasn't doing that before.
So a non-NULL dev->dma_io_tlb_mem should always be valid to follow.
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't
got round to saying that I've gone ahead and hacked up the alternative
(similarly untested) for comparison :)
TBH I'm still not sure which one I prefer...
Robin.
->8-
diff --git a/drivers/base/core.c b/drivers/base/core.c
index ea5b85354526..394abf184c1a 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2847,9 +2847,6 @@ void device_initialize(struct device *dev)
defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
dev->dma_coherent = dma_default_coherent;
#endif
-#ifdef CONFIG_SWIOTLB
- dev->dma_io_tlb_mem = io_tlb_default_mem;
-#endif
}
EXPORT_SYMBOL_GPL(device_initialize);
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 39284ff2a6cd..620f16d89a98 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -107,16 +107,21 @@ struct io_tlb_mem {
};
extern struct io_tlb_mem *io_tlb_default_mem;
+static inline struct io_tlb_mem *dev_iotlb_mem(struct device *dev)
+{
+ return dev->dma_io_tlb_mem ?: io_tlb_default_mem;
+}
+
static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t
paddr)
{
- struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
+ struct io_tlb_mem *mem = dev_iotlb_mem(dev);
return mem && paddr >= mem->start && paddr < mem->end;
}
static inline bool is_swiotlb_force_bounce(struct device *dev)
{
- struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
+ struct io_tlb_mem *mem = dev_iotlb_mem(dev);
return mem && mem->force_bounce;
}
@@ -167,7 +172,7 @@ bool swiotlb_free(struct device *dev, struct page
*page, size_t size);
static inline bool is_swiotlb_for_alloc(struct device *dev)
{
- return dev->dma_io_tlb_mem->for_alloc;
+ return dev_iotlb_mem(dev)->for_alloc;
}
#else
static inline struct page *swiotlb_alloc(struct device *dev, size_t size)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index b7f76bca89bf..f4942149f87d 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -359,7 +359,7 @@ static unsigned int swiotlb_align_offset(struct
device *dev, u64 addr)
static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr,
size_t size,
enum dma_data_direction dir)
{
- struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
+ struct io_tlb_mem *mem = dev_iotlb_mem(dev);
int index = (tlb_addr - mem->start) >> IO_TLB_SHIFT;
phys_addr_t orig_addr = mem->slots[index].orig_addr;
size_t alloc_size = mem->slots[index].alloc_size;
@@ -440,7 +440,7 @@ static unsigned int wrap_index(struct io_tlb_mem
*mem, unsigned int index)
static int swiotlb_find_slots(struct device *dev, phys_addr_t orig_addr,
size_t alloc_size)
{
- struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
+ struct io_tlb_mem *mem = dev_iotlb_mem(dev);
unsigned long boundary_mask = dma_get_seg_boundary(dev);
dma_addr_t tbl_dma_addr =
phys_to_dma_unencrypted(dev, mem->start) & boundary_mask;
@@ -522,7 +522,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device
*dev, phys_addr_t orig_addr,
size_t mapping_size, size_t alloc_size,
enum dma_data_direction dir, unsigned long attrs)
{
- struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
+ struct io_tlb_mem *mem = dev_iotlb_mem(dev);
unsigned int offset =
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06.07.2021 15:34, Andrew Cooper wrote:
> On 06/07/2021 13:03, Jan Beulich wrote:
>> On 06.07.2021 13:23, Andrew Cooper wrote:
>>> 'count * sizeof(*pfns)' can in principle overflow, but is implausible in
>>> practice as the time between checkpoints is typically sub-second.
>>> Nevertheless, simplify the code and remove the risk.
>>>
>>> There is no need to loop over the bitmap to calculate count. The number of
>>> set bits is returned in xc_shadow_op_stats_t which is already collected (and
>>> ignored).
>>>
>>> Bounds check the count against what will fit in REC_LENGTH_MAX. At the time
>>> of writing, this allows up to 0xff pfns.
>> Well, okay, this then means that an overflow in the reporting of
>> dirty_count doesn't matter for now, because the limit is lower
>> anyway.
>>
>>> Rearrange the pfns loop to check
>>> for errors both ways, not simply that there were more pfns than expected.
>> Hmm, "both ways" to me would mean ...
>>
>>> @@ -459,24 +462,20 @@ static int send_checkpoint_dirty_pfn_list(struct
>>> xc_sr_context *ctx)
>>> goto err;
>>> }
>>>
>>> -for ( i = 0, written = 0; i < ctx->restore.p2m_size; ++i )
>>> +for ( i = 0, written = 0; count && i < ctx->restore.p2m_size; ++i,
>>> --count )
>>> {
>>> if ( !test_bit(i, dirty_bitmap) )
>>> continue;
>>>
>>> -if ( written > count )
>>> -{
>>> -ERROR("Dirty pfn list exceed");
>>> -goto err;
>>> -}
>>> -
>>> pfns[written++] = i;
>>> }
>>>
>>> -rec.length = count * sizeof(*pfns);
>>> -
>>> -iov[1].iov_base = pfns;
>>> -iov[1].iov_len = rec.length;
>>> +if ( written != stats.dirty_count )
>>> +{
>>> +ERROR("Mismatch between dirty bitmap bits (%u), and dirty_count
>>> (%u)",
>>> + written, stats.dirty_count);
>>> +goto err;
>>> +}
>> ... you then also check that there are no further bit set in the
>> bitmap. As said elsewhere, I'm not convinced using statistics as
>> a basis for actual operation (rather than just reporting) is
>> appropriate.
>
> I'm not interested in inference based on the name of the structure.
I'm afraid that's the problem: Because you started using it for
something it wasn't meant to be used for, you now think it's the
name that's misleading, and the use is okay. I remain of the
opinion that it's the other way around (but see below for there
not being an real dependency at least in this particular case).
>> I'm unaware of there being any spelled out guarantee
>> that the numbers reported back from the hypercall are accurate.
>
> The live loop uses this information already for this purpose. If it is
> wrong, we've got bigger problems that this.
send_memory_live() passes the value to send_dirty_pages(), which
in turn passes it only to xc_report_progress_step() and uses it
in
if ( written > entries )
DPRINTF("Bitmap contained more entries than expected...");
There's no relying on this number at all afaics.
Jan
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06.07.2021 15:19, Andrew Cooper wrote: > On 06/07/2021 13:58, Olaf Hering wrote: >> Am Tue, 6 Jul 2021 12:23:32 +0100 >> schrieb Andrew Cooper : >> >>> +count = stats.dirty_count; >> Is this accurate? > > The live loop relies on it, and it worked correctly the last time I > tested it. When still merely investigating in preparation of my recent series, i.e. without having made changes yet except to add some logging, I did observe "Bitmap contained more entries than expected..." a couple of times, with "written" and "entries" typically apart by just 1 (as determined by extra logging; to be honest I don't recall if they were farther apart at any point). So the number is _not_ accurate in any event, and cannot be used for other than reporting purposes (as also expressed elsewhere on this thread). This also underlines that, unlike you did say in a reply to one of my patches, this is only a "detail" message, not an error, because migration happily went on and succeeded. Jan
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06/07/2021 14:39, Olaf Hering wrote: > Am Tue, 6 Jul 2021 14:22:58 +0100 > schrieb Andrew Cooper : > >> What hardware is this on? i.e. is the Page Modification Logging feature >> in use? > At least it gets reported as VMX feature during boot, this is a CoyotePass > system. That logging is problematic (that means "this hardware has the feature"), but yes - PML will be used by default when available. ~Andrew
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
Am Tue, 6 Jul 2021 14:22:58 +0100 schrieb Andrew Cooper : > What hardware is this on? i.e. is the Page Modification Logging feature > in use? At least it gets reported as VMX feature during boot, this is a CoyotePass system. Olaf pgpwQDzeiSuN6.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH 1/2] x86/mem-sharing: ensure consistent lock order in get_two_gfns()
On Tue, Jul 6, 2021 at 9:14 AM Jan Beulich wrote: > > On 06.07.2021 14:36, Tamas K Lengyel wrote: > > On Tue, Jun 29, 2021 at 8:54 AM Jan Beulich wrote: > >> > >> While the comment validly says "Sort by domain, if same domain by gfn", > >> the implementation also included equal domain IDs in the first part of > >> the check, thus rending the second part entirely dead and leaving > >> deadlock potential when there's only a single domain involved. > >> > >> Signed-off-by: Jan Beulich > > > > Acked-by: Tamas K Lengyel > > Thanks. Do you think I should queue this for backporting (once it got > applied)? Sure, considering it's a bugfix. Thanks, Tamas
Re: [PATCH] tools/xen-foreign: Update the size for vcpu_guest_{core_regs, context}
Hi Julien,
> On 6 Jul 2021, at 14:20, Julien Grall wrote:
>
> From: Julien Grall
>
> Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
> uint64_t") updated the size of the structure vcpu_guest_core_regs and
> indirectly vcpu_guest_context.
>
> On Arm, the two structures are only accessible to the tools and the
> hypervisor (and therefore stable). However, they are still checked
> by the scripts in tools/include/xen-foreign are not able to understand
> that.
>
> Ideally we should rework the scripts so we don't have to update
> the size for non-stable structure. But I don't have limited time
> to spend on the issue. So chose the simple solution and update
> the size accordingly.
>
> Note that we need to keep vcpu_guest_core_regs around because
> the structure is used by vcpu_guest_context and therefore the
> scripts expects the generated header to contain it.
>
> Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t")
> Reported-by: Andrew Cooper
> Signed-off-by: Julien Grall
Reviewed-by: Bertrand Marquis
But I have other issues now:
xg_dom_arm.c:143:15: error: format '%x' expects argument of type 'unsigned
int', but argument 3 has type 'uint64_t' {aka 'long long unsigned int'}
[-Werror=format=]
143 | DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
| ^~~
144 |ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
|
| |
| uint64_t {aka long long unsigned int}
We will work on a patch to fix those.
Cheers
Bertrand
>
> ---
>
> Cc: michal.or...@arm.com
> Cc: o...@aepfle.de
> ---
> tools/include/xen-foreign/reference.size | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/include/xen-foreign/reference.size
> b/tools/include/xen-foreign/reference.size
> index a0409db5c458..11a06a7a432c 100644
> --- a/tools/include/xen-foreign/reference.size
> +++ b/tools/include/xen-foreign/reference.size
> @@ -4,8 +4,8 @@ structs | arm32 arm64 x86_32 x86_64
> start_info| - -11121168
> trap_info | - - 8 16
> cpu_user_regs | - - 68 200
> -vcpu_guest_core_regs | 304 304 - -
> -vcpu_guest_context| 344 34428005168
> +vcpu_guest_core_regs | 312 312 - -
> +vcpu_guest_context| 352 35228005168
> arch_vcpu_info| 0 0 24 16
> vcpu_time_info| 32 32 32 32
> vcpu_info | 48 48 64 64
> --
> 2.17.1
>
>
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06/07/2021 13:03, Jan Beulich wrote:
> On 06.07.2021 13:23, Andrew Cooper wrote:
>> 'count * sizeof(*pfns)' can in principle overflow, but is implausible in
>> practice as the time between checkpoints is typically sub-second.
>> Nevertheless, simplify the code and remove the risk.
>>
>> There is no need to loop over the bitmap to calculate count. The number of
>> set bits is returned in xc_shadow_op_stats_t which is already collected (and
>> ignored).
>>
>> Bounds check the count against what will fit in REC_LENGTH_MAX. At the time
>> of writing, this allows up to 0xff pfns.
> Well, okay, this then means that an overflow in the reporting of
> dirty_count doesn't matter for now, because the limit is lower
> anyway.
>
>> Rearrange the pfns loop to check
>> for errors both ways, not simply that there were more pfns than expected.
> Hmm, "both ways" to me would mean ...
>
>> @@ -459,24 +462,20 @@ static int send_checkpoint_dirty_pfn_list(struct
>> xc_sr_context *ctx)
>> goto err;
>> }
>>
>> -for ( i = 0, written = 0; i < ctx->restore.p2m_size; ++i )
>> +for ( i = 0, written = 0; count && i < ctx->restore.p2m_size; ++i,
>> --count )
>> {
>> if ( !test_bit(i, dirty_bitmap) )
>> continue;
>>
>> -if ( written > count )
>> -{
>> -ERROR("Dirty pfn list exceed");
>> -goto err;
>> -}
>> -
>> pfns[written++] = i;
>> }
>>
>> -rec.length = count * sizeof(*pfns);
>> -
>> -iov[1].iov_base = pfns;
>> -iov[1].iov_len = rec.length;
>> +if ( written != stats.dirty_count )
>> +{
>> +ERROR("Mismatch between dirty bitmap bits (%u), and dirty_count
>> (%u)",
>> + written, stats.dirty_count);
>> +goto err;
>> +}
> ... you then also check that there are no further bit set in the
> bitmap. As said elsewhere, I'm not convinced using statistics as
> a basis for actual operation (rather than just reporting) is
> appropriate.
I'm not interested in inference based on the name of the structure.
> I'm unaware of there being any spelled out guarantee
> that the numbers reported back from the hypercall are accurate.
The live loop uses this information already for this purpose. If it is
wrong, we've got bigger problems that this.
~Andrew
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
Am Tue, 6 Jul 2021 14:19:21 +0100 schrieb Andrew Cooper : > > 20: faults= 0 dirty= 80 > > What is this showing, other than (unsurprisingly) faults doesn't work > for an HVM guest? The dirty count goes down after a while for a domU that constantly touches as many pages as it can. But yes, the current code uses stats.dirty_count in a number of places. It seems all of the usage is just for reporting, so if these code paths would get wrong input nothing bad happens. precopy_policy may indicate more or less iterations, this is not critical either. Olaf pgpkmcjruoj13.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
> > So at this point, the AMD IOMMU driver does:
> >
> > swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
> >
> > where 'swiotlb' is a global variable indicating whether or not swiotlb
> > is in use. It's picked up a bit later on by pci_swiotlb_late_init(), which
> > will call swiotlb_exit() if 'swiotlb' is false.
> >
> > Now, that used to work fine, because swiotlb_exit() clears
> > 'io_tlb_default_mem' to NULL, but now with the restricted DMA changes, I
> > think that all the devices which have successfully probed beforehand will
> > have stale pointers to the freed structure in their 'dev->dma_io_tlb_mem'
> > field.
>
> Yeah. I don't think we can do that anymore, and I also think it is
> a bad idea to start with.
I've had a crack at reworking things along the following lines:
- io_tlb_default_mem now lives in the BSS, the flexible array member
is now a pointer and that part is allocated dynamically (downside of
this is an extra indirection to get at the slots).
- io_tlb_default_mem.nslabs tells you whether the thing is valid
- swiotlb_exit() frees the slots array and clears the rest of the
structure to 0. I also extended it to free the actual slabs, but I'm
not sure why it wasn't doing that before.
So a non-NULL dev->dma_io_tlb_mem should always be valid to follow.
Untested diff below... Nathan, it would be ace if you're brave enough
to give this a shot.
Will
--->8
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbad7c559901..9e1218f89e4b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2820,7 +2820,7 @@ void device_initialize(struct device *dev)
dev->dma_coherent = dma_default_coherent;
#endif
#ifdef CONFIG_SWIOTLB
- dev->dma_io_tlb_mem = io_tlb_default_mem;
+ dev->dma_io_tlb_mem = _tlb_default_mem;
#endif
}
EXPORT_SYMBOL_GPL(device_initialize);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 785ec7e8be01..f06d9b4f1e0f 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -164,7 +164,7 @@ int __ref xen_swiotlb_init(void)
int rc = -ENOMEM;
char *start;
- if (io_tlb_default_mem != NULL) {
+ if (io_tlb_default_mem.nslabs) {
pr_warn("swiotlb buffer already initialized\n");
return -EEXIST;
}
@@ -547,7 +547,7 @@ xen_swiotlb_sync_sg_for_device(struct device *dev, struct
scatterlist *sgl,
static int
xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
- return xen_phys_to_dma(hwdev, io_tlb_default_mem->end - 1) <= mask;
+ return xen_phys_to_dma(hwdev, io_tlb_default_mem.end - 1) <= mask;
}
const struct dma_map_ops xen_swiotlb_dma_ops = {
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 39284ff2a6cd..b0cb2a9973f4 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -103,9 +103,9 @@ struct io_tlb_mem {
phys_addr_t orig_addr;
size_t alloc_size;
unsigned int list;
- } slots[];
+ } *slots;
};
-extern struct io_tlb_mem *io_tlb_default_mem;
+extern struct io_tlb_mem io_tlb_default_mem;
static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
{
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 0ffbaae9fba2..91cd1d413027 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -70,7 +70,7 @@
enum swiotlb_force swiotlb_force;
-struct io_tlb_mem *io_tlb_default_mem;
+struct io_tlb_mem io_tlb_default_mem;
/*
* Max segment that we can provide which (if pages are contingous) will
@@ -101,7 +101,7 @@ early_param("swiotlb", setup_io_tlb_npages);
unsigned int swiotlb_max_segment(void)
{
- return io_tlb_default_mem ? max_segment : 0;
+ return io_tlb_default_mem.nslabs ? max_segment : 0;
}
EXPORT_SYMBOL_GPL(swiotlb_max_segment);
@@ -134,9 +134,9 @@ void __init swiotlb_adjust_size(unsigned long size)
void swiotlb_print_info(void)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = _tlb_default_mem;
- if (!mem) {
+ if (!mem->nslabs) {
pr_warn("No low mem\n");
return;
}
@@ -163,11 +163,11 @@ static inline unsigned long nr_slots(u64 val)
*/
void __init swiotlb_update_mem_attributes(void)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = _tlb_default_mem;
void *vaddr;
unsigned long bytes;
- if (!mem || mem->late_alloc)
+ if (!mem->nslabs || mem->late_alloc)
return;
vaddr = phys_to_virt(mem->start);
bytes = PAGE_ALIGN(mem->nslabs << IO_TLB_SHIFT);
@@ -201,25 +201,24 @@ static void swiotlb_init_io_tlb_mem(struct io_tlb_mem
*mem, phys_addr_t start,
int __init swiotlb_init_with_tbl(char *tlb,
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06/07/2021 14:19, Andrew Cooper wrote: > On 06/07/2021 13:58, Olaf Hering wrote: >> Am Tue, 6 Jul 2021 12:23:32 +0100 >> schrieb Andrew Cooper : >> >>> +count = stats.dirty_count; >> Is this accurate? > The live loop relies on it, and it worked correctly the last time I > tested it. > >> I remember the reporting is broken since a while, and testing a busy domU >> indicates it is still the case. > If its broken, it needs fixing. > >> # xen-logdirty `xl domid domU` >> 0: faults= 0 dirty= 258050 >> 1: faults= 0 dirty= 257817 >> 2: faults= 0 dirty= 253713 >> 3: faults= 0 dirty= 253197 >> 4: faults= 0 dirty= 255154 >> 5: faults= 0 dirty= 260876 >> 6: faults= 0 dirty= 259083 >> 7: faults= 0 dirty= 253163 >> 8: faults= 0 dirty= 258349 >> 9: faults= 0 dirty= 260330 >> 10: faults= 0 dirty= 259754 >> 11: faults= 0 dirty= 257273 >> 12: faults= 0 dirty= 255756 >> 13: faults= 0 dirty= 258209 >> 14: faults= 0 dirty= 257847 >> 15: faults= 0 dirty= 59639 >> 16: faults= 0 dirty= 81 >> 17: faults= 0 dirty= 86 >> 18: faults= 0 dirty= 111 >> 19: faults= 0 dirty= 81 >> 20: faults= 0 dirty= 80 > What is this showing, other than (unsurprisingly) faults doesn't work > for an HVM guest? Sorry - I meant HAP guest. What hardware is this on? i.e. is the Page Modification Logging feature in use? ~Andrew
[PATCH] tools/xen-foreign: Update the size for vcpu_guest_{core_regs, context}
From: Julien Grall
Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t") updated the size of the structure vcpu_guest_core_regs and
indirectly vcpu_guest_context.
On Arm, the two structures are only accessible to the tools and the
hypervisor (and therefore stable). However, they are still checked
by the scripts in tools/include/xen-foreign are not able to understand
that.
Ideally we should rework the scripts so we don't have to update
the size for non-stable structure. But I don't have limited time
to spend on the issue. So chose the simple solution and update
the size accordingly.
Note that we need to keep vcpu_guest_core_regs around because
the structure is used by vcpu_guest_context and therefore the
scripts expects the generated header to contain it.
Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t")
Reported-by: Andrew Cooper
Signed-off-by: Julien Grall
---
Cc: michal.or...@arm.com
Cc: o...@aepfle.de
---
tools/include/xen-foreign/reference.size | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/include/xen-foreign/reference.size
b/tools/include/xen-foreign/reference.size
index a0409db5c458..11a06a7a432c 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -4,8 +4,8 @@ structs | arm32 arm64 x86_32 x86_64
start_info| - -11121168
trap_info | - - 8 16
cpu_user_regs | - - 68 200
-vcpu_guest_core_regs | 304 304 - -
-vcpu_guest_context| 344 34428005168
+vcpu_guest_core_regs | 312 312 - -
+vcpu_guest_context| 352 35228005168
arch_vcpu_info| 0 0 24 16
vcpu_time_info| 32 32 32 32
vcpu_info | 48 48 64 64
--
2.17.1
[xen-unstable-smoke test] 163328: regressions - trouble: blocked/fail
flight 163328 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 163326 build-arm64-xsm 6 xen-buildfail REGR. vs. 163326 build-armhf 6 xen-buildfail REGR. vs. 163326 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen f17a73b3c0264c62dd6b5dae01ed621c051c3038 baseline version: xen 4473f3601098a2c3cf5ab89d5a29504772985e3a Last test of basis 163326 2021-07-06 09:01:40 Z0 days Testing same since 163328 2021-07-06 13:01:47 Z0 days1 attempts People who touched revisions under test: Marek Marczykowski-Górecki Michal Orzel Olaf Hering jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit f17a73b3c0264c62dd6b5dae01ed621c051c3038 Author: Olaf Hering Date: Thu Jul 1 11:56:08 2021 +0200 tools/migration: unify type checking for data pfns in migration stream Introduce a helper which decides if a given pfn type has data in the migration stream. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Reviewed-by: Juergen Gross commit 5588ebcfca774477cf823949e5703b0ac48818cc Author: Olaf Hering Date: Thu Jul 1 11:56:07 2021 +0200 tools/migration: unify type checking for data pfns in the VM Introduce a helper which decides if a given pfn in the migration stream is backed by memory. This highlights more clearly that type XEN_DOMCTL_PFINFO_XALLOC (a synthetic toolstack-only type used between Xen 4.2 to 4.5 which indicated a dirty page on the sending side for which no data will be send in the initial iteration) does get populated in the VM. No change in behaviour intended, except for invalid page types which now have a safer default. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper commit 9e59d9f8ee3808acde9833192211da25f66d8cc2 Author: Olaf Hering Date: Thu Jul 1 11:56:05 2021 +0200 tools/migration: unify known page type checking Users of xc_get_pfn_type_batch may want to sanity check the data returned by Xen. Add helpers for this purpose: is_known_page_type verifies the type returned by Xen on the saving side, or the incoming type for a page on the restoring side, is known by the save/restore code. Signed-off-by: Olaf Hering Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper commit a27976a1080d537fb1f212a8f9133d60daa0025b Author: Olaf Hering Date: Thu Jul 1 11:56:01 2021 +0200 tools/python: fix Python3.4 TypeError in format string Using the first element of a tuple for a format specifier fails with python3.4 as included in SLE12: b = b"string/%x" % (i, ) TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple' It happens to work with python 2.7 and 3.6. To support older Py3, format as strings and explicitly encode as ASCII. Signed-off-by: Olaf Hering Reviewed-by: Andrew Cooper Acked-by: Marek
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06/07/2021 13:58, Olaf Hering wrote: > Am Tue, 6 Jul 2021 12:23:32 +0100 > schrieb Andrew Cooper : > >> +count = stats.dirty_count; > Is this accurate? The live loop relies on it, and it worked correctly the last time I tested it. > I remember the reporting is broken since a while, and testing a busy domU > indicates it is still the case. If its broken, it needs fixing. > # xen-logdirty `xl domid domU` > 0: faults= 0 dirty= 258050 > 1: faults= 0 dirty= 257817 > 2: faults= 0 dirty= 253713 > 3: faults= 0 dirty= 253197 > 4: faults= 0 dirty= 255154 > 5: faults= 0 dirty= 260876 > 6: faults= 0 dirty= 259083 > 7: faults= 0 dirty= 253163 > 8: faults= 0 dirty= 258349 > 9: faults= 0 dirty= 260330 > 10: faults= 0 dirty= 259754 > 11: faults= 0 dirty= 257273 > 12: faults= 0 dirty= 255756 > 13: faults= 0 dirty= 258209 > 14: faults= 0 dirty= 257847 > 15: faults= 0 dirty= 59639 > 16: faults= 0 dirty= 81 > 17: faults= 0 dirty= 86 > 18: faults= 0 dirty= 111 > 19: faults= 0 dirty= 81 > 20: faults= 0 dirty= 80 What is this showing, other than (unsurprisingly) faults doesn't work for an HVM guest? ~Andrew
Re: [PATCH 1/2] x86/mem-sharing: ensure consistent lock order in get_two_gfns()
On 06.07.2021 14:36, Tamas K Lengyel wrote: > On Tue, Jun 29, 2021 at 8:54 AM Jan Beulich wrote: >> >> While the comment validly says "Sort by domain, if same domain by gfn", >> the implementation also included equal domain IDs in the first part of >> the check, thus rending the second part entirely dead and leaving >> deadlock potential when there's only a single domain involved. >> >> Signed-off-by: Jan Beulich > > Acked-by: Tamas K Lengyel Thanks. Do you think I should queue this for backporting (once it got applied)? Jan
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
Am Tue, 6 Jul 2021 12:23:32 +0100
schrieb Andrew Cooper :
> +count = stats.dirty_count;
Is this accurate?
I remember the reporting is broken since a while, and testing a busy domU
indicates it is still the case.
# xen-logdirty `xl domid domU`
0: faults= 0 dirty= 258050
1: faults= 0 dirty= 257817
2: faults= 0 dirty= 253713
3: faults= 0 dirty= 253197
4: faults= 0 dirty= 255154
5: faults= 0 dirty= 260876
6: faults= 0 dirty= 259083
7: faults= 0 dirty= 253163
8: faults= 0 dirty= 258349
9: faults= 0 dirty= 260330
10: faults= 0 dirty= 259754
11: faults= 0 dirty= 257273
12: faults= 0 dirty= 255756
13: faults= 0 dirty= 258209
14: faults= 0 dirty= 257847
15: faults= 0 dirty= 59639
16: faults= 0 dirty= 81
17: faults= 0 dirty= 86
18: faults= 0 dirty= 111
19: faults= 0 dirty= 81
20: faults= 0 dirty= 80
Olaf
/* gcc -Wall -o logdirty -O -lxenctrl logdirty.c */
#include
#include
#include
#include
#include
#include
#include
#define PAGE_SHIFT XC_PAGE_SHIFT
#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
#define NRPAGES(x) (ROUNDUP(x, PAGE_SHIFT) >> PAGE_SHIFT)
#define BITS_PER_LONG (sizeof(unsigned long) * 8)
#define ORDER_LONG (sizeof(unsigned long) == 4 ? 5 : 6)
static unsigned int domid = 0;
static xc_interface *xch;
static unsigned long xdmg(xc_interface *c, unsigned int d)
{
unsigned long r;
#if XEN_DOMCTL_INTERFACE_VERSION < 0x0b
r = xc_domain_maximum_gpfn(c, d);
#else
xen_pfn_t gpfns = 0;
r = xc_domain_maximum_gpfn(c, d, );
#endif
return r + 1;
}
static void sigint_handler(int sig)
{
int rc;
fprintf(stderr, "User aborted\n");
rc = xc_shadow_control(xch, domid, XEN_DOMCTL_SHADOW_OP_OFF, NULL, 0, NULL, 0, NULL);
if (rc < 0)
perror("XEN_DOMCTL_SHADOW_OP_OFF hypercall failed\n");
exit(1);
}
static inline int bitmap_size(int nr_bits)
{
int nr_long, nr_bytes;
nr_long = (nr_bits + BITS_PER_LONG - 1) >> ORDER_LONG;
nr_bytes = nr_long * sizeof(unsigned long);
return nr_bytes;
}
int main(int argc, char *argv[])
{
int rc, ret = 1, i, runs = 42;
unsigned int lflags;
xentoollog_level lvl;
xentoollog_logger *l;
DECLARE_HYPERCALL_BUFFER(unsigned long, to_skip);
unsigned long p2m_size;
xc_shadow_op_stats_t stats;
errno = EINVAL;
if (argc > 1)
domid = atoi(argv[1]);
if (!domid)
goto out;
if (argc > 2)
runs = atoi(argv[2]);
if (!runs)
goto out;
errno = 0;
lvl = XTL_DEBUG;
lflags = XTL_STDIOSTREAM_SHOW_PID | XTL_STDIOSTREAM_HIDE_PROGRESS;
l = (xentoollog_logger *) xtl_createlogger_stdiostream(stderr, lvl, lflags);
if (!l)
goto out;
xch = xc_interface_open(l, 0, 0);
if (!xch)
goto out;
p2m_size = xdmg(xch, domid);
if (!p2m_size)
goto out;
to_skip = xc_hypercall_buffer_alloc_pages(xch, to_skip, NRPAGES(bitmap_size(p2m_size)));
if (!to_skip)
goto out;
signal(SIGINT, sigint_handler);
rc = xc_shadow_control(xch, domid, XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY, NULL, 0, NULL, 0, NULL);
if (rc < 0) {
rc = xc_shadow_control(xch, domid, XEN_DOMCTL_SHADOW_OP_OFF, NULL, 0, NULL, 0, NULL);
if (rc < 0)
goto out;
rc = xc_shadow_control(xch, domid, XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY, NULL, 0, NULL, 0, NULL);
if (rc < 0)
goto out;
}
rc = xc_shadow_control(xch, domid, XEN_DOMCTL_SHADOW_OP_CLEAN, NULL, 0, NULL, 0, NULL);
if (rc < 0)
goto out;
for (i = 0; i < runs; i++) {
sleep(1);
if (1)
rc = xc_shadow_control(xch, domid, XEN_DOMCTL_SHADOW_OP_CLEAN, HYPERCALL_BUFFER(to_skip), p2m_size, NULL, 0, );
if (rc < 0)
goto out;
printf("%d: faults= %" PRIu32 " dirty= %" PRIu32 "\n", i, stats.fault_count, stats.dirty_count);
}
rc = xc_shadow_control(xch, domid, XEN_DOMCTL_SHADOW_OP_OFF, NULL, 0, NULL, 0, NULL);
if (rc < 0)
goto out;
errno = ret = 0;
out:
perror(argv[0]);
return ret;
}
pgpUjgpPjbjEs.pgp
Description: Digitale Signatur von OpenPGP
Re: [PATCH v4] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
Hi, On 06/07/2021 13:50, Michal Orzel wrote: On 06.07.2021 14:31, Julien Grall wrote: On 06/07/2021 13:30, Michal Orzel wrote: Hi, On 06.07.2021 14:00, Olaf Hering wrote: Am Mon, 5 Jul 2021 08:39:52 +0200 schrieb Michal Orzel : Modify type of hsr, cpsr, spsr_el1 to uint64_t. I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which fails to build: ... diff -u reference.size tmp.size --- reference.size 2021-06-29 10:50:32.237518309 +0200 +++ tmp.size 2021-07-06 13:58:19.052592351 +0200 @@ -4,8 +4,8 @@ start_info | - - 1112 1168 trap_info | - - 8 16 cpu_user_regs | - - 68 200 -vcpu_guest_core_regs | 304 304 - - -vcpu_guest_context | 344 344 2800 5168 +vcpu_guest_core_regs | 312 312 - - +vcpu_guest_context | 352 352 2800 5168 arch_vcpu_info | 0 0 24 16 vcpu_time_info | 32 32 32 32 vcpu_info | 48 48 64 64 gmake[2]: *** [Makefile:24: check-headers] Error 1 osstest may catch this error as well. Olaf Where does this report come from so that I can investigate it? Locally I can build this patch on arm64,arm32,x86 without any issues. This is coming from the tools/include/xen-foreign. I could reproduce it with a: make tools I am currently writing a patch for it. I will send it once I have tested it. Cheers, Cheers, Michal As far as I understand this checker, it is all about the size of these structures. What is the reason that the size of them cannot change? Those structures are meant to be part of the stable ABI. So you would break compatibility if the structure size changed across Xen version. However, we know that vcpu_guest_core_regs and vcpu_guest_context are not part of the stable ABI on Arm. However, the tools doesn't understand that... Cheers, -- Julien Grall
Re: [PATCH v4] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
On 06.07.2021 14:31, Julien Grall wrote: > > > On 06/07/2021 13:30, Michal Orzel wrote: >> Hi, >> >> On 06.07.2021 14:00, Olaf Hering wrote: >>> Am Mon, 5 Jul 2021 08:39:52 +0200 >>> schrieb Michal Orzel : >>> Modify type of hsr, cpsr, spsr_el1 to uint64_t. >>> >>> I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which >>> fails to build: >>> >>> ... >>> diff -u reference.size tmp.size >>> --- reference.size 2021-06-29 10:50:32.237518309 +0200 >>> +++ tmp.size 2021-07-06 13:58:19.052592351 +0200 >>> @@ -4,8 +4,8 @@ >>> start_info | - - 1112 1168 >>> trap_info | - - 8 16 >>> cpu_user_regs | - - 68 200 >>> -vcpu_guest_core_regs | 304 304 - - >>> -vcpu_guest_context | 344 344 2800 5168 >>> +vcpu_guest_core_regs | 312 312 - - >>> +vcpu_guest_context | 352 352 2800 5168 >>> arch_vcpu_info | 0 0 24 16 >>> vcpu_time_info | 32 32 32 32 >>> vcpu_info | 48 48 64 64 >>> gmake[2]: *** [Makefile:24: check-headers] Error 1 >>> >>> osstest may catch this error as well. >>> >>> Olaf >>> >> >> Where does this report come from so that I can investigate it? >> Locally I can build this patch on arm64,arm32,x86 without any issues. > > This is coming from the tools/include/xen-foreign. I could reproduce it with > a: > > make tools > > I am currently writing a patch for it. I will send it once I have tested it. > > Cheers, > >> >> Cheers, >> Michal >> > As far as I understand this checker, it is all about the size of these structures. What is the reason that the size of them cannot change? Cheers,
Re: [PATCH 14/16] paged_pages field is MEM_PAGING-only
On Mon, Jul 5, 2021 at 12:14 PM Jan Beulich wrote: > > Conditionalize it and its uses accordingly. > > Signed-off-by: Jan Beulich For the mem_sharing bits: Acked-by: Tamas K Lengyel The rest also look fine to me as you can consider having an R-b as well for those bits.
Re: [PATCH 13/16] shr_pages field is MEM_SHARING-only
On Mon, Jul 5, 2021 at 12:13 PM Jan Beulich wrote: > > Conditionalize it and its uses accordingly. The main goal though is to > demonstrate that x86's p2m_teardown() is now empty when !HVM, which in > particular means the last remaining use of p2m_lock() in this cases goes > away. > > Signed-off-by: Jan Beulich Reviewed-by: Tamas K Lengyel
Re: [PATCH 2/2] x86/mem-sharing: mov {get,put}_two_gfns()
On Tue, Jun 29, 2021 at 8:54 AM Jan Beulich wrote: > > There's no reason for every CU including p2m.h to have these two > functions compiled, when they're both mem-sharing specific right now and > for the foreseeable future. > > Largely just code movement, with some style tweaks, the inline-s > dropped, and "put" being made consistent with "get" as to their NULL > checking of the passed in pointer to struct two_gfns. > > Signed-off-by: Jan Beulich Acked-by: Tamas K Lengyel
Re: [PATCH] bus: Make remove callback return void
On Tue, Jul 06, 2021 at 01:17:37PM +0200, Cornelia Huck wrote:
> On Tue, Jul 06 2021, Cornelia Huck wrote:
>
> > On Tue, Jul 06 2021, Uwe Kleine-König
> > wrote:
> >
> >> The driver core ignores the return value of this callback because there
> >> is only little it can do when a device disappears.
> >>
> >> This is the final bit of a long lasting cleanup quest where several
> >> buses were converted to also return void from their remove callback.
> >> Additionally some resource leaks were fixed that were caused by drivers
> >> returning an error code in the expectation that the driver won't go
> >> away.
> >>
> >> With struct bus_type::remove returning void it's prevented that newly
> >> implemented buses return an ignored error code and so don't anticipate
> >> wrong expectations for driver authors.
> >
> > Yay!
> >
> >>
> >> Signed-off-by: Uwe Kleine-König
> >> ---
> >> Hello,
> >>
> >> this patch depends on "PCI: endpoint: Make struct pci_epf_driver::remove
> >> return void" that is not yet applied, see
> >> https://lore.kernel.org/r/20210223090757.57604-1-u.kleine-koe...@pengutronix.de.
> >>
> >> I tested it using allmodconfig on amd64 and arm, but I wouldn't be
> >> surprised if I still missed to convert a driver. So it would be great to
> >> get this into next early after the merge window closes.
> >
> > I'm afraid you missed the s390-specific busses in drivers/s390/cio/
> > (css/ccw/ccwgroup).
:-\
> The change for vfio/mdev looks good.
>
> The following should do the trick for s390; not sure if other
> architectures have easy-to-miss busses as well.
>
> diff --git a/drivers/s390/cio/ccwgroup.c b/drivers/s390/cio/ccwgroup.c
> index 9748165e08e9..a66f416138ab 100644
> --- a/drivers/s390/cio/ccwgroup.c
> +++ b/drivers/s390/cio/ccwgroup.c
> @@ -439,17 +439,15 @@ module_exit(cleanup_ccwgroup);
>
> /** driver stuff **/
>
> -static int ccwgroup_remove(struct device *dev)
> +static void ccwgroup_remove(struct device *dev)
> {
> struct ccwgroup_device *gdev = to_ccwgroupdev(dev);
> struct ccwgroup_driver *gdrv = to_ccwgroupdrv(dev->driver);
>
> if (!dev->driver)
> - return 0;
> + return;
This is fine to be squashed into my patch. In the long run: in a remove
callback dev->driver cannot be NULL, so this if could go away.
> if (gdrv->remove)
> gdrv->remove(gdev);
> -
> - return 0;
> }
>
> static void ccwgroup_shutdown(struct device *dev)
> diff --git a/drivers/s390/cio/css.c b/drivers/s390/cio/css.c
> index a974943c27da..ebc321edba51 100644
> --- a/drivers/s390/cio/css.c
> +++ b/drivers/s390/cio/css.c
> @@ -1371,15 +1371,14 @@ static int css_probe(struct device *dev)
> return ret;
> }
>
> -static int css_remove(struct device *dev)
> +static void css_remove(struct device *dev)
> {
> struct subchannel *sch;
> - int ret;
>
> sch = to_subchannel(dev);
> - ret = sch->driver->remove ? sch->driver->remove(sch) : 0;
> + if (sch->driver->remove)
> + sch->driver->remove(sch);
Maybe the return type for this function pointer can be changed to void,
too.
I will add these changes to a v2 that I plan to send out after the dust
settles some more.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[xen-unstable-smoke test] 163326: tolerable all pass - PUSHED
flight 163326 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163326/ 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 4473f3601098a2c3cf5ab89d5a29504772985e3a baseline version: xen 44e8904ebfbc57ba0950c40b9d3a28507b553e4e Last test of basis 163314 2021-07-05 15:00:28 Z0 days Testing same since 163326 2021-07-06 09:01:40 Z0 days1 attempts People who touched revisions under test: Julien Grall Oleksandr Tyshchenko Sergiy Kibrik 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 44e8904ebf..4473f36010 4473f3601098a2c3cf5ab89d5a29504772985e3a -> smoke
Re: [PATCH 1/2] x86/mem-sharing: ensure consistent lock order in get_two_gfns()
On Tue, Jun 29, 2021 at 8:54 AM Jan Beulich wrote: > > While the comment validly says "Sort by domain, if same domain by gfn", > the implementation also included equal domain IDs in the first part of > the check, thus rending the second part entirely dead and leaving > deadlock potential when there's only a single domain involved. > > Signed-off-by: Jan Beulich Acked-by: Tamas K Lengyel
Re: [PATCH v4] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
On 06/07/2021 13:30, Michal Orzel wrote: Hi, On 06.07.2021 14:00, Olaf Hering wrote: Am Mon, 5 Jul 2021 08:39:52 +0200 schrieb Michal Orzel : Modify type of hsr, cpsr, spsr_el1 to uint64_t. I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which fails to build: ... diff -u reference.size tmp.size --- reference.size 2021-06-29 10:50:32.237518309 +0200 +++ tmp.size2021-07-06 13:58:19.052592351 +0200 @@ -4,8 +4,8 @@ start_info| - -11121168 trap_info | - - 8 16 cpu_user_regs | - - 68 200 -vcpu_guest_core_regs | 304 304 - - -vcpu_guest_context| 344 34428005168 +vcpu_guest_core_regs | 312 312 - - +vcpu_guest_context| 352 35228005168 arch_vcpu_info| 0 0 24 16 vcpu_time_info| 32 32 32 32 vcpu_info | 48 48 64 64 gmake[2]: *** [Makefile:24: check-headers] Error 1 osstest may catch this error as well. Olaf Where does this report come from so that I can investigate it? Locally I can build this patch on arm64,arm32,x86 without any issues. This is coming from the tools/include/xen-foreign. I could reproduce it with a: make tools I am currently writing a patch for it. I will send it once I have tested it. Cheers, Cheers, Michal -- Julien Grall
Re: [PATCH v4] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
Hi, On 06.07.2021 14:00, Olaf Hering wrote: > Am Mon, 5 Jul 2021 08:39:52 +0200 > schrieb Michal Orzel : > >> Modify type of hsr, cpsr, spsr_el1 to uint64_t. > > I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which > fails to build: > > ... > diff -u reference.size tmp.size > --- reference.size 2021-06-29 10:50:32.237518309 +0200 > +++ tmp.size2021-07-06 13:58:19.052592351 +0200 > @@ -4,8 +4,8 @@ > start_info| - -11121168 > trap_info | - - 8 16 > cpu_user_regs | - - 68 200 > -vcpu_guest_core_regs | 304 304 - - > -vcpu_guest_context| 344 34428005168 > +vcpu_guest_core_regs | 312 312 - - > +vcpu_guest_context| 352 35228005168 > arch_vcpu_info| 0 0 24 16 > vcpu_time_info| 32 32 32 32 > vcpu_info | 48 48 64 64 > gmake[2]: *** [Makefile:24: check-headers] Error 1 > > osstest may catch this error as well. > > Olaf > Where does this report come from so that I can investigate it? Locally I can build this patch on arm64,arm32,x86 without any issues. Cheers, Michal
Re: [RESEND PATCH V5 0/2] Virtio support for toolstack on Arm (Was "IOREQ feature (+ virtio-mmio) on Arm")
Hello all, Gentle reminder... On 21.05.21 22:45, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Hello all. The purpose of this patch series is to add missing virtio-mmio bits to Xen toolstack on Arm. The Virtio support for toolstack [1] was postponed as the main target was to upstream IOREQ/DM support on Arm in the first place. Now, we already have IOREQ support in, so we can resume Virtio enabling work. You can find previous discussion at [2]. Patch series [3] was reworked and rebased on recent "staging branch" (972ba1d x86/shadow: streamline shadow_get_page_from_l1e()) and tested on Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with "updated" virtio-mmio disk backend [4] running in Driver domain and unmodified Linux Guest running on existing virtio-blk driver (frontend). No issues were observed. Guest domain 'reboot/destroy' use-cases work properly. Any feedback/help would be highly appreciated. [1] https://lore.kernel.org/xen-devel/1610488352-18494-24-git-send-email-olekst...@gmail.com/ https://lore.kernel.org/xen-devel/1610488352-18494-25-git-send-email-olekst...@gmail.com/ [2] https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02403.html https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02536.html [3] https://github.com/otyshchenko1/xen/commits/libxl_virtio [4] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml3 Julien Grall (1): libxl: Introduce basic virtio-mmio support on Arm Oleksandr Tyshchenko (1): libxl: Add support for Virtio disk configuration docs/man/xl-disk-configuration.5.pod.in | 27 + tools/include/libxl.h | 6 + tools/libs/light/libxl_arm.c | 133 - tools/libs/light/libxl_device.c | 38 +- tools/libs/light/libxl_disk.c | 99 +++- tools/libs/light/libxl_types.idl | 4 + tools/libs/light/libxl_types_internal.idl | 1 + tools/libs/light/libxl_utils.c| 2 + tools/libs/util/libxlu_disk_l.c | 881 +++--- tools/libs/util/libxlu_disk_l.h | 2 +- tools/libs/util/libxlu_disk_l.l | 1 + tools/xl/xl_block.c | 11 + xen/include/public/arch-arm.h | 7 + 13 files changed, 764 insertions(+), 448 deletions(-) -- Regards, Oleksandr Tyshchenko
Re: [PATCH 1/2] tools/migration: Fix iovec handling in send_checkpoint_dirty_pfn_list()
Am Tue, 6 Jul 2021 12:23:31 +0100 schrieb Andrew Cooper : > We shouldn't be using two struct iovec's to write half of 'rec' each, and > there is no need to malloc() for two struct iovec's at all. > > Simplify down to just two - one covering the whole of 'rec', and one covering > the pfns array. Acked-by: Olaf Hering Olaf pgpPX6CvBsDYl.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v4] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
On 06/07/2021 13:00, Olaf Hering wrote: > Am Mon, 5 Jul 2021 08:39:52 +0200 > schrieb Michal Orzel : > >> Modify type of hsr, cpsr, spsr_el1 to uint64_t. > I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which > fails to build: > > ... > diff -u reference.size tmp.size > --- reference.size 2021-06-29 10:50:32.237518309 +0200 > +++ tmp.size2021-07-06 13:58:19.052592351 +0200 > @@ -4,8 +4,8 @@ > start_info| - -11121168 > trap_info | - - 8 16 > cpu_user_regs | - - 68 200 > -vcpu_guest_core_regs | 304 304 - - > -vcpu_guest_context| 344 34428005168 > +vcpu_guest_core_regs | 312 312 - - > +vcpu_guest_context| 352 35228005168 > arch_vcpu_info| 0 0 24 16 > vcpu_time_info| 32 32 32 32 > vcpu_info | 48 48 64 64 > gmake[2]: *** [Makefile:24: check-headers] Error 1 > > osstest may catch this error as well. I've just reported the same on IRC too. Gitlab is currently a wall of red from 07d6dd51a5c508cc0f3c93a876f8b4e3102ecf60 so won't usefully highlight this, but OSSTest ought to notice in due course. Of course, there's copious quantities of information about what this check is actually trying to do, and why it's present... ~Andrew
Re: [Kvmtool] Some thoughts on using kvmtool Virtio for Xen
Hello Wei, Sorry for the late response. And thanks for working in that direction and preparing the document. On 05.07.21 13:02, Wei Chen wrote: Hi Stefano, Thanks for your comments. -Original Message- From: Stefano Stabellini Sent: 2021年6月30日 8:43 To: w...@kernel.org; julien.thierry.k...@gmail.com; Wei Chen Cc: k...@vger.kernel.org; xen-de...@lists.xen.org; jean-phili...@linaro.org; Julien Grall ; Andre Przywara ; Marc Zyngier ; Stefano Stabellini ; Oleksandr Tyshchenko Subject: Re: [Kvmtool] Some thoughts on using kvmtool Virtio for Xen Hi Wei, Sorry for the late reply. On Tue, 15 Jun 2021, Wei Chen wrote: Hi, I have some thoughts of using kvmtool Virtio implementation for Xen. I copied my markdown file to this email. If you have time, could you please help me review it? Any feedback is welcome! # Some thoughts on using kvmtool Virtio for Xen ## Background Xen community is working on adding VIRTIO capability to Xen. And we're working on VIRTIO backend of Xen. But except QEMU can support virtio-net for x86-xen, there is not any VIRTIO backend can support Xen. Because of the community's strong voice of Out-of-QEMU, we want to find a light weight VIRTIO backend to support Xen. Yes, having something light weight to provide Virtio backends for the at least *main* devices (console, blk, net) which we could run on Xen without an extra effort would be really nice. We have an idea of utilizing the virtio implementaton of kvmtool for Xen. And We know there was some agreement that kvmtool won't try to be a full QEMU alternative. So we have written two proposals in following content for communities to discuss in public: ## Proposals ### 1. Introduce a new "dm-only" command 1. Introduce a new "dm-only" command to provide a pure device model mode. In this mode, kvmtool only handles IO request. VM creation and initialization will be bypassed. * We will rework the interface between the virtio code and the rest of kvmtool, to use just the minimal set of information. At the end, there would be MMIO accesses and shared memory that control the device model, so that could be abstracted to do away with any KVM specifics at all. If this is workable, we will send the first set of patches to introduce this interface, and adapt the existing kvmtool to it. Then later we will can add Xen support on top of it. About Xen support, we will detect the presence of Xen libraries, also allow people to ignore them, as kvmtoll do with optional features like libz or libaio. Idealy, we want to move all code replying on Xen libraries to a set of new files. In this case, thes files can only be compiled when Xen libraries are detected. But if we can't decouple this code completely, we may introduce a bit of #ifdefs to protect this code. If kvm or other VMM do not need "dm-only" mode. Or "dm-only" can not work without Xen libraries. We will make "dm-only" command depends on the presence of Xen libraries. So a normal compile (without the Xen libraries installed) would create a binary as close as possible to the current code, and only the people who having Xen libraries installed would ever generate a "dm-only" capable kvmtool. ### 2. Abstract kvmtool virtio implementation as a library 1. Add a kvmtool Makefile target to generate a virtio library. In this scenario, not just Xen, but any project else want to provide a userspace virtio backend service can link to this virtio libraris. These users would benefit from the VIRTIO implementation of kvmtool and will participate in improvements, upgrades, and maintenance of the VIRTIO libraries. * In this case, Xen part code will not upstream to kvmtool repo, it would then be natural parts of the xen repo, in xen/tools or maintained in other repo. We will have a completely separate VIRTIO backend for Xen, just linking to kvmtool's VIRTIO library. * The main changes of kvmtool would be: 1. Still need to rework the interface between the virtio code and the rest of kvmtool, to abstract the whole virtio implementation into a library 2. Modify current build system to add a new virtio library target. I don't really have a preference between the two. From my past experience with Xen enablement in QEMU, I can say that the Xen part of receiving IO emulation requests is actually pretty minimal. In general, both proposals sound good to me, probably with a little preference for #1, but I am not sure that I can see all pitfalls here. Yes, we have done some prototyping, and the code of Xen receive IOREQ support can be implemented in a separate new file without invasion into the existing kvmtool. The point is that the device implementation calls the hypervisor interfaces to handle these IOREQs, and is currently
Re: [PATCH 0/2] tools/migration: Fixes in send_checkpoint_dirty_pfn_list()
On 06.07.2021 13:23, Andrew Cooper wrote: > These are a prerequisite to all currently on-list patches touching the > function. Just as an observation, while I can see how from your pov (judging from your not-exactly-review-comments) patch 2 may be a prereq to one of my changes, I don't think I'd call patch 1 a prereq to anything - this is cleanup which can be done at any point. Of course it'll allow me to shrink that one of my patches, which is certainly nice. Jan
Re: [PATCH 2/2] tools/migration: Fix potential overflow in send_checkpoint_dirty_pfn_list()
On 06.07.2021 13:23, Andrew Cooper wrote:
> 'count * sizeof(*pfns)' can in principle overflow, but is implausible in
> practice as the time between checkpoints is typically sub-second.
> Nevertheless, simplify the code and remove the risk.
>
> There is no need to loop over the bitmap to calculate count. The number of
> set bits is returned in xc_shadow_op_stats_t which is already collected (and
> ignored).
>
> Bounds check the count against what will fit in REC_LENGTH_MAX. At the time
> of writing, this allows up to 0xff pfns.
Well, okay, this then means that an overflow in the reporting of
dirty_count doesn't matter for now, because the limit is lower
anyway.
> Rearrange the pfns loop to check
> for errors both ways, not simply that there were more pfns than expected.
Hmm, "both ways" to me would mean ...
> @@ -459,24 +462,20 @@ static int send_checkpoint_dirty_pfn_list(struct
> xc_sr_context *ctx)
> goto err;
> }
>
> -for ( i = 0, written = 0; i < ctx->restore.p2m_size; ++i )
> +for ( i = 0, written = 0; count && i < ctx->restore.p2m_size; ++i,
> --count )
> {
> if ( !test_bit(i, dirty_bitmap) )
> continue;
>
> -if ( written > count )
> -{
> -ERROR("Dirty pfn list exceed");
> -goto err;
> -}
> -
> pfns[written++] = i;
> }
>
> -rec.length = count * sizeof(*pfns);
> -
> -iov[1].iov_base = pfns;
> -iov[1].iov_len = rec.length;
> +if ( written != stats.dirty_count )
> +{
> +ERROR("Mismatch between dirty bitmap bits (%u), and dirty_count
> (%u)",
> + written, stats.dirty_count);
> +goto err;
> +}
... you then also check that there are no further bit set in the
bitmap. As said elsewhere, I'm not convinced using statistics as
a basis for actual operation (rather than just reporting) is
appropriate. I'm unaware of there being any spelled out guarantee
that the numbers reported back from the hypercall are accurate.
Jan
Re: [PATCH v4] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
Am Mon, 5 Jul 2021 08:39:52 +0200 schrieb Michal Orzel : > Modify type of hsr, cpsr, spsr_el1 to uint64_t. I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which fails to build: ... diff -u reference.size tmp.size --- reference.size 2021-06-29 10:50:32.237518309 +0200 +++ tmp.size2021-07-06 13:58:19.052592351 +0200 @@ -4,8 +4,8 @@ start_info| - -11121168 trap_info | - - 8 16 cpu_user_regs | - - 68 200 -vcpu_guest_core_regs | 304 304 - - -vcpu_guest_context| 344 34428005168 +vcpu_guest_core_regs | 312 312 - - +vcpu_guest_context| 352 35228005168 arch_vcpu_info| 0 0 24 16 vcpu_time_info| 32 32 32 32 vcpu_info | 48 48 64 64 gmake[2]: *** [Makefile:24: check-headers] Error 1 osstest may catch this error as well. Olaf pgpgaGoeGfIFm.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH 1/2] tools/migration: Fix iovec handling in send_checkpoint_dirty_pfn_list()
On 06.07.2021 13:23, Andrew Cooper wrote: > We shouldn't be using two struct iovec's to write half of 'rec' each, and > there is no need to malloc() for two struct iovec's at all. I was indeed wondering about all of these while also touching the function. But I was guessing that there might be a deeper reason I don't see. > Simplify down to just two - one covering the whole of 'rec', and one covering > the pfns array. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Jan
[qemu-mainline test] 163321: tolerable FAIL - PUSHED
flight 163321 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/163321/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 163311 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 163311 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 163311 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 163311 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 163311 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 163311 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 163311 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-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-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 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass version targeted for testing: qemuu9bef7ea9d93ee6b6297a5be6cb5a557f7d1764c9 baseline version: qemuu4fb2820854a796ab75ffb2ec896b67268281ecde Last test of basis 163311 2021-07-05 12:09:09 Z0 days Testing same since 163321 2021-07-06 00:39:14 Z0 days1 attempts People who touched revisions under test: Christian Schoenebeck Daniel P. Berrangé Dr. David Alan Gilbert Feng Lin Greg Kurz Hyman Huang(黄勇) Laurent Vivier Li Zhijian Peter Maydell Peter Xu Vivek Goyal jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf
